Что будет, если "отвалится" клиентская машина.



Posted by Аркадий Водяник on July 10, 1999 at 23:37:54:

In Reply to: Re: Точка зpения posted by Андpей Акопянц on July 10, 1999 at 12:04:03:

Андрей Акопянц пишет:

2. С точки зрения технологий - давайте сосредоточимся на одной-единственной вещи:
что у вас делается с традиционными СУБД-шными транзакциями в многопользовательском режиме?
Т.е. в ситуации, когда пользователь А начал менять данные, но еще не закончил,
что увидит пользователь Б, обратившийся за этими данными? А что увидит пользователь А?
И что произойдет, если станция пользователя А отвалится, не успев завершить модификацию?
И как это реализовано?

Рассмотрим ситуацию, когда пользователь А вводит операцию в ФБП:Клиенте.
Сначала он строит фразу этой операции, делая последовательные выборы из меню и списков.
Пока он не завершил построение фразы, ни FBP:Сервер, ни тем более пользователь Б еще ничего
не знают об этой операции.
И вот пользователь А добрался до конца фразы и нажал в последний раз Enter.
Клиент формирует запрос к Серверу такого, например, вида:

o mc=7 dc=1 1000 .Касса.расход.выдача под отчет.|71-12 Иванов.

Этот запрос записывается в каталог обмена с Сервером в файл X.REQ. (В действительности,
конечно же, используется не имя X, а что-нибудь вроде случайно полученного Q67TY940, но
для данного вопроса это неважно). Запись в файл занимает какое-то хоть и малое время,
и во время этой записи есть вероятность, что станция пользователя А "отвалится". Ну и пусть!
Ведь этот файл X.REQ - еще не запрос. И никто ничего не увидит - ни снова подключившийся А,
ни все время остававшийся на связи с Сервером пользователь Б.

Запросом файл X.REQ станет, когда Клиент переименует его в файл X.IN. Все, теперь Сервер
при очередном сканировании каталога обмена заметит X.IN, обработает, т.e. в файле хозяйственных
операций появится очередная запись. Если после переименования станция А "отвалится" - это
уже неважно; дело сделано и сделано до конца. Теперь пользователь Б увидит эту новую операцию,
точно так же, как и вновь подключившийся пользователь А.

Может ли станция А отвалиться в момент переименования? Конечно, может! Но ведь переименование
делается файлсерверной частью той машины, где расположен ФБП:Сервер. То есть, если успел
дойти до файлсервера запрос на переименование от редиректора станции - переименование
состоится. A если не успел - то нет. В любом случае не будет никаких промежуточных фаз.
Вероятость потерять целостность данных из-за "отвала" станции равна в точности нулю.

Итак, мы рассмотрели ввод операции. При модификации операции все выглядит почти так же.
Только вместо

o mc=7 dc=1 1000 .Касса.расход.выдача под отчет.|71-12 Иванов.

На сервер уйдет запрос вида:

o key=GASB-017 .Касса.расход.выдача под отчет.|71-12 Иванов.

где GASB-017 - уникальный код операции, присвоенный Сервером при ее вводе.
Обмен с ФБП:Сервером будет происходить так же, как уже было описано.
Это же относится и ко всем другим возможным запросам: удалению операции, заведению счетов,
выполнению форм и т.д. В файле запроса может быть много строк - например, групповая операция,
или комбинация разнородных запросов - ФБП:Сервер не будет отвлекаться на что либо-другое,
пока не обработает этот запрос (эквивалент транзакции в общепринятом смысле).

Стоит отметить, что и свои ответы ФБП:Сервер формирует не сразу в файле *.OUT, а сначала
в *.ANS, и уже готовый *.ANS переименовывает в *.OUT; это тоже способствует тому,
чтобы недоразумения не возникали.

Все эти переименования - существенный элемент надежности ФБП. Такой подход позволяет уйти
от решения тонких вопросов о методе открытия файла в каталоге обмена, не задумываться о том,
как работает с файлами та или иная система.

Для дальнейшего изучения вопроса имеет смысл снова обратиться к сообщению 322.
Там также рассмотрено, что такое транзакция применительно к ФБП.




Пpишедшие ответы: