CC BY
44
УДК 004.416.6
И.Г. Боровской, Д.П. Вагнер
Координатор распределенных действий для БД в многопользовательской среде
Рассмотрена проблема координации распределенных действий в многопользовательской среде на примере настольных баз данных, использование которых в некоторых случаях приводит к искажению и потере информации. Исследованы стандартные механизмы решения проблемы с помощью инструмента блокировок данных; на основе выявленных недостатков предложено решение — разработка координатора распределенных транзакций с использованием технологии обмена данными Windows Socket.
Необходимость координации действий в информационных системах наиболее четко обозначилась с появлением многопользовательских и многопрограммных сред. В настоящее время проблема координации распределенных действий для ряда пользователей не является проблемой как таковой, поскольку в большинстве систем она уже решена разработчиками. Наиболее яркий пример — базы данных: в этом случае речь идет о координации транзакций, параллельное выполнение которых не должно приводить к искажению либо потере данных. В большинстве современных СУБД ответственность за проведение транзакций возложена на координатор распределенных транзакций. Так, например, при работе MS SQL Server используется системная служба Windows — Distributed Transaction Coordinator (DTC), которая отвечает за координацию транзакций, относящихся не только непосредственно к СУБД, но также и к очередям сообщений, файловым системам и другим ресурсам [1]. Однако существуют системы, в которых решение проблемы координации действий не было заложено изначально по ряду причин: использование систем в * домашних условиях», небольшая вероятность возникновения конфликтных ситуаций, невысокая стоимость программного обеспечения, следствием чего была ограниченность функциональных возможностей и т.д. При использовании таких систем резкий рост пользователей и увеличение объема обрабатываемых данных зачастую могут приводить к возникновению ранее не появлявшихся проблем с искажением и потерей данных. В качестве практического примера авторами была рассмотрена проблема координации распределенных транзакций для настольных баз данных (Microsoft Access), при использовании которых нарушения при выполнении запросов на обработку данных становятся критическими и не могут быть решены стандартными средствами.
Microsoft Access (MS Access) в настоящее время является одной из наиболее популярных СУБД, используемых для разработки настольных баз данных. Это обусловлено несколькими факторами: приложение предоставляет не только широкий набор средств создания, поиска, управления и обработки данных, но также включает удобные механизмы визуального конструирования и настройки интерфейса. Кроме того, немаловажным фактором, обусловливающим широкое распространение MS Access, является полная интеграция с другими приложениями Microsoft Office (MS Word, MS Excel и т.д.), а также использование Visual Basic for Applications (VBA) при решении более сложных задач автоматизации либо создания интерфейса пользователя [2].
Подобная популярность в настоящее время привела к тому, что настольные базы данных зачастую используются в качестве основы для клиент-серверной технологии при разработке базы данных на предприятиях различного масштаба. Нередко такая база данных функционирует в сетевом многопользовательском режиме без координации доступа к данным, что может приводить к искажению либо потере информации. Например, в некоторых ситуациях число одновременно работающих с данными клиентов может достигать нескольких десятков, кроме того, на предприятии зачастую могут использоваться автоматизированные средства добавления или обновления информации. В таком случае и возникают ситуации, когда вероятность] потери либо искажения информации при попытке одновременной работы с записями таблиц существенноувеличивается.
Описанные проблемы были выявлены в результате вычислительного эксперимента,: в котором несколько рабочих потоков осуществляли одновременную вставку записей в количестве от 25 до 100 в таблицу MS Access, имеющую поле с уникальным ключом. Эксперимент показал, что уже в случае двух рабочих потоков потери записей в связи с повторением у ни-
И.Г. Боровской, Д.П. Вагнер. Координатор распределенных действий для БД ..
75
кального ключа при вставке достигают 32-40 %, при наличия трех — уже 39-50 %, а при четырех потоках — 58-65 % [3].
В подобных ситуациях возникает необходимость в ограничении числа обращающихся пользователей к данным, однако при использовании MS Access данная проблема не может быть решена стандартными средствами. В этом случае решение вопроса о координации доступа к данным возлагается на разработчика БД, в распоряжении которого имеется лишь несколько базовых инструментов, позволяющих производить операции блокировки данных в многопользовательском режиме.
Процессор баз данных обеспечивает три уровня блокировок:
1) блокировка базы данных — на этом уровне блокировки к базе данных может обращаться только один пользователь. Такой уровень блокировки применяется для глобального изменения или обновления данных или при техническом обслуживании базы данных — восстановлении или сжатии;
2) блокировка таблицы — на этом уровне блокировки к таблице может обращаться только один пользователь. Только после проведения изменений клиентом и закрытия к таблице получат доступ другие пользователи. Следует отметить, что при открытии базы данных Access уже при наличии блокировки таблицы (во время работы приложения) данная таблица открывается без извещения диалоговым окном о блокировке таблицы. Однако операции по добавлению записей или их редактированию будут невозможны. Данный уровень блокировки применяется в тех случаях, когда необходимо обработать сразу несколько записей таблицы;
3) блокировка страницы — самым нижним уровнем блокировки является уровень страницы. Процессор Microsoft Jet автоматически устанавливает блокировку страницы, которая далее не может контролироваться программой. Страница данных может содержать несколько записей, размер которых равен 26 Кбайт. Блокировка страницы приводит к блокировке всех записей, находящихся на этой странице [4].
Блокировка на уровне таблицы имеет два режима — пессимистический и оптимистический. По умолчанию устанавливается пессимистическая блокировка.
Пессимистическая блокировка блокирует страницу при проведении операций редактирования и добавления, страница остается заблокированной до тех пор, пока не будет выполнено обновление. В течение всего времени ни одна программа не имеет доступа к заблокированной странице. Данный способ обеспечивает максимально возможный уровень целостности данных, однако в этом случае страница может быть заблокирована в течение продолжительного времени.
Оптимистическая блокировка блокирует страницу только при вызове методов обновления. Это означает, что пользователь производит необходимые действия с данными и только в момент сохранения обновления процессор Microsoft Jet пытается заблокировать страницу. При успешном завершении операций запись попадает в таблицу, но если обнаружится, что эта запись уже была отредактирована, то обновление отменяется и пользователь получает соответствующее сообщение о том, что данные уже были изменены. При таком способе страница блокируется на минимально возможное время, тем самым уменьшается число сообщений о блокировках, однако это может привести к ошибкам блокировки при одновременном редактировании записи несколькими пользователями [4].
Как видно, описанные выше способы использования инструмента блокировок позволяют в некоторых случаях управлять доступом различных пользователей к данным и осуществлять координацию действий при работе с записями. Однако использование этих инструментов связано с большими трудностями при планировании и реализации готовых систем и зачастую позволяет лишь частично решить проблемы, связанные с ограничением доступа к данным, а комплексных методов решения указанной проблемы у разработчика настольных баз данных нет.
Одним из путей решения рассматриваемой проблемы является использование предлагаемого авторами координатора распределенных действий для работы в многопользовательской среде. В основе данного подхода лежит схема взаимодействия клиентской и серверной частей, использующая методы оповещения клиентов о текущем состоянии сервера и предоставления монопольного доступа клиенту к данным, а также её реализация на основе выбранного средства синхронизации.
Алгоритм работы предложенной схемы реализуется на следующих принципах:
• для упорядочивания взаимодействия всех клиентов на сервере, то есть машине, на которой физически расположена база данных, используется «сервер транзакций*
(приложение-сервер), а на клиентских машинах — «клиентский компонент» (приложение-клиент);
• сервер осуществляет постоянную работу и в любой момент времени находится в одном из двух состояний: «свободен» или «занят»;
• сервер предоставляет монопольный доступ к необходимым данным одному клиенту;
• в том случае, если сервер находится в состоянии «свободен», произвольный клиент имеет возможность к нему обратиться, после чего осуществляет необходимые операции с данными. В этом случае сервер переходит в состояние «занят» вплоть до окончания всех операций клиента;
• если при обращении к серверу клиент получает уведомление о том, что сервер «занят», клиент становится в режим «ожидания» и получает доступ к серверу только по окончании работы с ним предыдущего клиента;
• неустойчивая работа любого из клиентов, например сбой, зависание, отключение питания, не оказывает влияния на работу сервера или других клиентов [3].
Приведенная на рисунке схема позволяет обеспечить необходимый уровень защиты данных при одновременной работе с ними большого числа клиентов, ведь доступ к данным в произвольный момент времени будет иметь только один клиент, а остальные будут находиться в режиме ожидания.
Схема взаимодействия сервера и клиентов
Для реализации предложенной схемы необходимо выбрать эффективное средство синхронизации и передачи данных между сервером и клиентом. При анализе возможных технологий следует иметь в виду, что взаимодействие сервера и клиентов будет осуществляться в локальной сети предприятия, а потому необходимо учитывать все особенности межсетевого обмена данными. Авторами были рассмотрены следующие технологии: взаимодействия посредством использования операций с файлами, с именованными каналами (Named Pipes) и сокетами (Windows Sockets).
Использование файлов в данной ситуации выглядит наиболее простым и очевидным решением. В таком случае взаимодействие может осуществляться с использованием операций чтения и записи в файл, расположенный на машине сервере. При этом файл может играть роль как «флага», информирующего всех о текущем состоянии сервера, так и буфера обмена данными. Такой способ взаимодействия, казалось бы, удовлетворяет предъявляемым требованиям, однако возможна следующая ситуация: клиент осуществил запись в файл некоторой части информации, но по какой-либо причине не смог продолжить работу, например произошел сбой сетевого оборудования или «зависла» машины клиента. В этом случае информация, переданная клиентом, останется необработанной и сервер, ожидающий возобновления работы, будет в течение продолжительного времени недоступен остальным клиентам. Как видно, данный способ имеет существенный недостаток — высокую степень зависимости от устойчивой работы клиента.
Развитием идеи использования файлов служит технология на основе именованных каналов (Named Pipes).
Именованные каналы — это объекты ядра операционной системы, являющиеся средством межпроцессной коммуникации между сервером канала и одним или несколькими клиентами канала. Сервером канала называется процесс, создающий именованный канал. Клиентом канала называется процесс, подключающийся к созданному именованному каналу. Базовым объектом для реализации именованных каналов служит объект «файл», поэтому для посылки и приема сообщений по именованным каналам используются те же самые функции Window API (Application Program Interface), что и при работе с файлами (ReadFile, WriteFile).
При создании именованного канала ему назначается уникальное имя, определяется максимальное количество одновременных соединений с клиентами канала и режим работы канала (должен ли канал быть односторонним или двусторонним (дуплексным), ведется ли передача пакетами или потоком байтов и т.п.).
Именованные каналы отличаются следующими возможностями: гарантированная доставка сообщений, асинхронный ввод/вывод, коммуникация между процессами на разных компьютерах в локальной вычислительной сети и относительная простота использования [5],
Таким образом, для организации взаимодействия клиентского и серверного компонентов использование данной технологии приемлемо, поскольку именованные каналы удовлетворяют большинству предъявляемых требований. Однако эта технология все же имеет существенный недостаток: создание именованных каналов возможно только в NT-системах, хотя подключение к созданному каналу возможно как в NT-системах, так и в Win9x.
Windows Socket (сокеты) — механизм, позволяющий независимо от протокола передачи данных организовать сетевой интерфейс между двумя компьютерами в сети. В частности, сокеты могут работать как с протоколом TCP, так и с протоколом UDP. Обращение к сокету происходит по IP-адресу машины, на которой был создан Windows Socket, и номеру порта.
Различают сокеты с установлением соединения, то есть адреса сокетов отправителя и получателя выясняются заранее, до передачи сообщений между ними — устанавливается так называемый виртуальный канал между двумя машинами в сети, и без установления соединения — адреса сокетов отправителя и получателя передаются с каждым пересылаемым сообщением. Для каждого сокета назначается тип, посредством которого определяется способ передачи данных между двумя сокетами. Тип Windows Socket с установлением соединения — это виртуальный канал, а тип Windows Socket без установления соединения — дейтаграмма. В первом случае используется протокол TCP, отличающийся высокой степенью надежности при передаче данных. При этом появляется возможность мгновенно отслеживать состояние канала (соединения по сокету), что в свою очередь позволит корректно разграничить доступ к данным. Во втором случае используется протокол UDP, при этом надежность передачи данных оказывается существенно ниже, однако к преимуществам данного способа относится более высокая скорость работы,
Сокеты с установлением соединения взаимодействуют по схеме клиент/сервер: серверному покету назначается общеизвестный адрес и он непрерывно ожидает прибытия клиентских сообщений. Клиентский процесс посылает сообщения на сервер по объявленному адресу серверного сокета [5].
Одним из преимуществ сокетов является и тот факт, что большинство современных операционных систем (Windows, Unix, Linux) поддерживает сокеты на уровне встроенных в ядро библиотек.
Таким образом, авторами предлагается принципиальная схема координатора распределенных действий для настольных баз данных, который позволяет исключить потери информации при работе указанных БД в многопользовательской среде. Реализация координатора может быть основана на именованных каналах или сокетах. Последнее предпочтительно, поскольку охватывает весь диапазон Windows-платформ и Unix-систем вследствие универсальности сокетов.
Также стоит отметить, что использование координатора распределенных действий в сети, имеющей 35 активных подключений при доступе к базе данных объемом более 0,5 Гбайт, полностью исключило неопределенность операций. Например, вставка данных пользователями в таблицу, имеющую поле с уникальным ключом, больше не приводит к проблеме его дублирования. Кроме того, при возникновении ситуации сбоя любого из клиентов надежность и эффективность всей системы остаются неизменно высокими. К недочетам предлагаемой системы можно отнести то, что существует небольшая временная задержка в работе сервера, которая, впрочем, для пользователя является практически незаметной.
Литература
1. Microsoft Corporation. Администрирование Microsoft® SQL Server 7.0. Учебный курс: официальное пособие Microsoft для самостоятельной подготовки : пер. с англ. - М. : Русская Редакция, 2000. - 512 с.
2. Microsoft Corporation Microsoft Access 2000. Шаг за шагом: практ. пособие : пер. с англ. - М. : ЭКОМ, 2002. - 352 с.
3. Вагнер Д.П. Координатор распределенных транзакций для настольных баз данных / Д.П. Вагнер // Научная сессия ТУСУР - 2007 : материалы докладов Всероссийской научно-технической конференции студентов, аспирантов и молодых ученых, Томск, 3-7 мая 2007 г. - Томск : В-Спектр, 2007. - Ч. 1. - 346 с. - С. 342-345.
4. Виллариал Б. Программирование Access 2002 в примерах : пер. с англ. / Б. Виллари-ал. - М. : КУДИЦ-ОБРАЗ, 2003. - 496 с.
5. Соломон Д. Внутреннее устройство Microsoft Windows 2000. Мастер-класс / Д. Соломон, М. Руссинович ; пер. с англ. - СПб. : Питер; Русская Редакция, 2004. - 746 с.
Боровской Игорь Георгиевич
Проф., д-р физ.-мат. наук, зав. каф. экономической математики, информатики и статистики ТУСУРа Тел.: 41 49 878.
Вагнер Дмитрий Петрович
Аспирант каф. экономической математики, информатики и статистики ТУСУРа Эл. почта: adios@lenta.ru, adios@ef.fet.tusur.ru
I.G. Borovskoi, D.P. Vagner
Database coordinator of the distributed actions in the multiuser environment
In the article the problem of coordination of the distributed actions in the multiuser environment on an example of desktop databases which use in some cases results in distortion and loss of the information is cdnsidered. Standard mechanisms of the decision of a problem with the help of the tool of blocking of the data are investigated, on the basis of the revealed lacks the decision — development of the coordinator of the distributed transactions with use of technology of data exchange Windows Socket is offered.
