хотелось бы узнать, как можно реализовать оптимистическую и пессимистическую конкуренцию для учетных систем

сервер MSSQL2000, архитектура - обычный клиент-сервер. А тип сервера влияет на способ реализации? Разве нет каких-нибудь общих принципов?

Может быть мой вопрос глупый, но должна же как то обрабатываться ситуация, когда во время редактирования документа одним пользователем, другой пользователь этот же документ пытается удалить?

ок. как реализовать для приведенной выше конфигурации? Я планировал добавить в таблицы документов поле lock, и при открытии документа для редактирования выставлять его true, после закрытия false. Но есть проблема - если во время редактирования будет потеряно соединение, или приложение завершиться аварийно то документ так и останется заблокированным.
Если знаете механизмы для различных типов серверов, то опишите pls.

Спасибо. А не могли бы Вы немного пояснить:
[FOR UPDATE [OF ...]]
[WITH LOCK]

то есть данная запись блокируется на время выполнения данной транзакции? Я правильно понял?

ОК. Такой вариант был бы оптимальным. А mssql позволяет обрабатывать события открытия соединения, закрытия соединения?

to chad: понял, спасибо.

Насколько я понимаю, реализация механизма конкуренций при архитектуре клиент-сервер, без привязки к специфичеиким возможностям конкретного сервера невозможна?

chadНу на случай аварийного отключения можно сделать кнопку принудительного сброса блокировок.Или в клиенте при входе проверять не осталось ли блокировок от пользователя и их удалять.

Это вариант, но если например у одного из пользователей во время редактирования документа выходит из строя рабочая станция, то он должен бежать к соседней и запускать клиент под своим аккаунтом, заказчик смысл таких действий не поймет, да и ближайший компьютер может находится далеко. А разблокировать все документы сразу, по моему не очень корректно будет.

Dik76Пожалуй это не относится к оптимистической блокировке, только к писсимистической.
А можно поподробнее про оптимистическу блокировку?

понял, возможно два варианта: либо использовать средства сервера, либо приведенный в статье способ, но с недостатком: "... минус тут один: запись может висеть в заблокированном состоянии сколько угодно, поэтому желательно наличие какого-нибудь администратора, который может принудительно разблокировать любую запись."

MasterZiv
Пессимистическая тебе не грозит, если у тебя MSSQL - база раком встанет от длинных транзакций. Остается либо оптимистическая вообще ( т.е. вообще не пытаться обнаружить конфликты), либо оптимистическая с обнаружением конфликтов по
полю TIMESTAMP

всем (изменяемым или вообще всем) полям записи.

Конкретно как это реализуется надо писать, или знаешь ?


Реализацию хотелось бы увидеть, если не сложно...

Зы, а почему пессимистическая блокировка под MSSQL подразумевает длинные транзакции, соответствующую позу базы?

По поводу, того что данные конфликты _реально_ редки - скорей всего это так, но это не означает что их не бывает вообще, все зависит от специфики работы предприятия. А если следовать "правилам хорошего тона", то обработку подобных конфликтов в учетной системе реализовывать, по моему, нужно. По крайней мере во многих (если не во всех) коммерческих системах это реализовано.
Я вообще хотел узнать общие принципы, без привязки к средствам сервера, но по всей видимости, таковых нету.

Спасибо за хороший совет не быть слишком умным :) таковым себя и не считаю

MasterZiv Да уж, буду очень благодарен