Представим себе достаточно распространенную ситуацию: вы разрабатываете систему электронного документа-оборота, которая должна предоставлять возможность ввода и редактирования этих самых электронных документов. Документы хранятся в нормализованном виде (данные разложены по таблицам) в некоторой БД. Доступ к ним осуществляется по двух уровневой схеме. Необходимо обеспечить целостность данных конкретного документа с идентификатором ID, при возможности его редактирования с разных рабочих станций. Например: два пользователя изменяют один документ и по-очереди сохраняют данные. При этом первый из сохранивших сделает всю работу в пустую. Кроме того, результат от такого редактирования может оказаться фатальным т.к. помимо самого изменения документа, как правило, происходит корректировка других данных, сопровождающих документ. Для предотвращения ситуаций одновременного редактирования можно воспользоваться несколькими приемами.

Прием 1. Физическая блокировка в качестве логической блокировки.

При взятии документа на редактирование клиентом можно одновременно выполнять блокировку записи (ей) в таблицах БД. И если блокировка не удается, значит, эта запись заблокирована другим соединением. По завершении транзакции блокировка сама снимается. Также в случае разрыва соединения, блокировка будет снята.

Данный метод прост, надежен и даже не требует написания большого колличества вспомогательного кода. Однако, данный метод создает большое количество трудностей для программ с большим документооборотом, большим количеством одновременно работающих пользователей, или в том случае, когда приложение многоуровневое. Основным минусом данного метода является высокая "цена" за каждый заблокированный документ, т.к. нужно держать транзакцию открытой, а записи БД - заблокированными. И все только ради ограничения доступа к документу. В случае же с WEB приложениями данный способ вообще неприемлем.

Тогда и зарождается идея сделать не физическую, а логическую блокировку.

Прием 2. Простая защита от нарушения целостности данных.

Если решать проблему только целостноти данных и принять серьезное ограничение, что только что отредактированный документ может быть потерян, потому что его параллельно изменял другой человек, то задачу можно заметно упростить. В этом случае хорошо применим способ подкраски документа последним пользователем, взявшим его на редактирование. В таблице(ах) заводится дополнительная колонка подкраски. Когда пользователь берет документ на редактирование, в специальную колонку заносится некоторый уникальный ключ (это может быть и штамп времени). Об этом ключе знает только клиентское приложение и запись в БД. Если этот же документ будет редактировать другой пользователь, он занесет свой ключ, удалив старый. Сразу после занесения ключа транзакция зарывается. И ни каких ресурсов БД в течение редактирования документа на клиенте не расходуется. А главное, не требуется наличия постоянного соединения. По завершении редактирования, программа будет пытаться обновить документ с идентификатором и только ей известным ключом. Если вдруг, другой пользователь начал редактировать или уже редактировал этот документ, то ключ будет изменен этим пользователем. Тогда обновление не пройдет, т.к. документ с парой значений: "ID", "ключ", не найдется в БД и транзакцию придется откатить. Не очень гуманно, но действенно, и главное, максимально экономит ресурсы. Однако при очень большом колличестве пользователей, работающих с одной группой документов, произойдет паралич системы :(.

Возможно, просто нужен другой способ :).

Прием 3. Мусорка и мусорщик.

Это, пожалуй, самый распространенный прием после физических блокировок. Он очень похож на них. Перед тем, как взять документ на редактирование, мы должны запомнить ID документа, где-нибудь в БД или на среднем слое. Когда следующий пользователь попробует работать с этим документом, необходимо проверить, не занят ли этот ID, и если занят - запретить работать с документом. Когда пользователь закончит работу с документом, он должен удалить запись ID из списка заблокированных документов.

На первый взгляд все просто. Но, при ближайшем рассмотрении, вопросов возникает больше, чем ответов. Во первых, где гарантия, что все пользователи будут при редактировании заносить куда-то этот ID? Во вторых, где гарантия, что все будут удалять этот ID после редактирования? (Как быть в случае зависаний или просто программных ошибок? Со всеми бывает :) ).

Проблема не так сложна при наличии сервера приложения. Можно организовать единый механизм работы с документом и гарантировать удаление ID в случае проблем с клиентом. Но, так или иначе, нужно подбирать мусор - это мнимые ID незаблокированных документов. Короче, положа руку на сердце, - это, конечно, способ, но все же далекий от совершенства.

Прием 4. Договор.

Что можно назвать основной проблемой приема 3? Это сборка мусора. И если в случае с 3-х уровневой архитектурой это менее сложная задача, то в случае с 2-х уровневой, она практически не реализуема. Кроме того, прием 3 неприятен для WEB решений, т.к. вообще не понятно, как в этом случае подбирать мусор.

Если извлечь плюсы из приема 3 и попытаться устранить недостатки, то можно предложить следующий изящный способ.

Клиент заключает с сервером (средний слой, БД, WEB сервисы) ДОГОВОР о неприкосновенности документа, где говорится, что он, клиент, обязуется в указанный срок завершить работу с запрошенным документом (ID), или продлить договор. Иначе контракт на данный документ будет аннулирован.

В реализации, например, с БД это может означать следующее, прежде чем будет запрошен документ, открывается транзакция, которая проверяет, нет ли активного договора на запрашиваемый документ. Если он есть - извините, придется ждать. Если его нет - зеленый свет, мы заключаем договор на данный документ на разумное время (например, 4 мин)! Это значит, что ровно через четыре минуты наш договор станет, не действителен. В эти четыре минуты мы должны открыть новую транзакцию и сохранить документ, причем при сохранении договор должен присутствовать и быть актуальным. Последняя операция в этой транзакции - удаление договора. Если пользователю не достаточно этого времени, то клиент продляет договор, назначив новое время его окончания. Осталось при заключении нового договора добавить маленький код, удаляющий все просроченные договоры (так на всякий случай, вдруг какой-нибудь из клиентов завис).

Эта схема мне кажется привлекательной. Осталась всего одна проблема - правильный выбор времени договора. Если интервал слишком маленький - договор придется постоянно продлять. Слишком большой - придется ждать, в случае зависания клиента, пока не истечет срок договора. Тут один совет: это должно либо настраиваться, либо вообще обладать интеллектом, и время должно определяться динамически (в случае WEB решений).

Прочитав книгу ".Net Remoting"(Скотт Маклин, Джеймс Нафтел, Ким Уильямс, издательство "Русская редакция", Москва 2003), я обнаружил, что данная методика не нова. В System.Runtime.Remoting.Lifetime Namespace имеется интерфейс Isponsor, реализующий точно такую же логику, но не в рамках БД, а врамках приложения среднего слоя с использованием .Net Framework.

Резюме.

Если вам приходится писать приложения, работающие с БД, то вы рано или поздно столкнетесь с необходимостью создавать логические блокировки. В этой статье приведены наиболее стандартные способы решения этой проблемы. Ваш выбор должен определяться конкретной ситуацией, оценить которую можно по трем факторам:

1. Надежность
2. Ресурсоемкость
3. Простота реализации

Важно отметить, что создание среднего слоя всегда благотворно влияет на решение проблем такого типа, сочетая 1-ое и 2-ое качество, а использование .net помогает справиться и с третьей проблемой :).