Распределенные системы: технология Borland Midas. Часть 3. Фертиков В.В. - 10 стр.

                                     10
   также использовать этот тип с DCOM, HTTP, Sockets или OLEnterprise ком-
   понентами.
• TCorbaDataModule . Это сервер CORBA. Этот тип используется для обес-
   печения данными CORBA-клиентов.
      Со всеми этими типами модулей данных можно использовать невизуаль-
ные компоненты, поскольку непосредственным предком удаленного модуля
данных является обычный модуль данных, и унаследованные от него механиз-
мы обеспечивают взаимодействие компонентов доступа к данным с сервером
баз данных через BDE. Собственные механизмы удаленного модуля данных
обеспечивают взаимодействие с клиентами.
      Каждый удаленный модуль данных на сервере приложений содержит
один или несколько провайдеров, инкапсулированных компонентами TData-
SetProvider . Каждый набор данных клиента использует определенного про-
вайдера, который действует как мост между набором данных клиента и данны-
ми, которые представляет удаленный модуль данных. Провайдер заботится об
упаковке данных в пакеты, которые он посылает клиенту, и о приеме измене-
ний, полученных от клиента. Удаленный модуль данных делает каждый такой
провайдер доступным для клиента, поскольку позволяет предоставить DCOM-
интерфейс для соответствующих объектов, делая их управляемыми извне и
превращая, таким образом, сервер приложений в DCOM-сервер (см. ниже).
      В свою очередь, провайдер данных:
• получает запрос на данные от клиента, получает запрошенные данные от ба-
   зы данных, упаковывает данные для передачи и посылает их клиенту;
• получает измененные данные от клиента, применяет изменения к базе дан-
   ных и записывает все изменения, которые не могут быть применены, воз-
   вращает не примененные изменения клиенту для дальнейшего согласования.
      Относительно последнего пункта необходимо сделать следующее заме-
чание. Инфраструктура разрабатываемого распределенного приложения пре-
доставляет широкие возможности для решения характерных для многопользо-
вательского доступа к данным проблем, связанных с попытками одновременно-
го редактирования несколькими пользователями одних и тех же данных. Отме-
тим, что в данном случае механизм блокировок, используемый в традиционной
двухзвенной модели клиент-сервер, может оказаться неэффективным или даже
неприемлемым, так как промежуток времени между редактированием записи и
сохранением ее в базе данных может быть весьма длительным. Вместо этого
используется следующий механизм. При попытке сохранения сервером при-
ложений измененной записи в базе данных, прежде всего, производится ее по-
иск в соответствующем наборе данных на сервере приложений и сравнение
всех ее полей с исходными значениями. В данном случае под исходными пони-
маются значения, которые были в кэше клиента на момент получения этой за-
писи с сервера до того, как пользователь изменил в кэше эту запись. Таким пу-
тем автоматически выявляются потенциально опасные случаи параллельного
изменения одной и той же записи несколькими пользователями. Если какие-
либо поля за время между получением оригинала записи клиентом и попыткой
сохранить изменения были модифицированы другим пользователем, запись