Здравствуйте Sinclair, Вы писали:

S>Здравствуйте Al-Ko, Вы писали:

AK>>А скажите, поддерживает ли механизм транзакций такие возможности:

AK>>представим себе две связанные таблицы (один-ко-многим), допустим, накладная — перечень товаров. Один юзер выбрал запись с накладной номер NN, считал через SELECT перечень находящихся в ней товаров и редактирует этот перечень.
AK>>Второй юзер, не ведая того, что накладную NN выбрал первый, тоже считал ее и редактирует, хотя вроде как и не имеет на это право.

AK>>Есть ли возможность сообщить юзеру №2, что, хотя он прочел накладную NN, он не имеет право ее редактировать? Есть ли возможность сообщить юзеру №2, кто в данный момент редактирует накладную NN из других пользователей?

AK>>Или механизм транзакций может только сообщить юзеру №2 при сохранении накладной, что все изменения, которые он сделал, недействительны, так как данная запись "была изменена другим пользователем"?

Извините за SKIPPED — это самая классная статья по транзакциям, которая мне попадалась. Но...

Что pessimistic, что optimistic — такая реализация одновременного доступа только лишь с помощью транзакций не позволяет "спокойно" работать с такой простейшей базой данных, которая приведена в моем примере. У нас в сети всего три (очень редко четыре) компьютера, и между ними иногда происходят конфликты, связанные с одновременным доступом. Правильно, или ты ждешь неизвестно сколько, пока запись не освободится, или ты получаешь откат после вдумчивого редактирования накладной с пояснением, что ты не имеешь, оказывается, право эту накладную редактировать.

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

User Table Info(номер блокированного документа)
=================================================================
1 INVOICE 56
1 ORDER 12
2 INVOICE 55
3 INVOICE 57


итак, пользователь 1 зашел в накладную 56. При этом он может редактировать эту накладную, либо пить кофе в другой комнате (что тоже иногда встречается). Пользователь N, заходя в накладную 56, получает информацию из таблицы LOCKER, что накладная 56 заблокирована пользователем 1. Он может читать из накладной 56 информацию, но никогда не начнет ее бесполезное редактирование. Как только пользователь 1 ушел с накладной 56, в таблице LOCKER исчезла эта строка("1 INVOICE 56") и накладная свободна для других пользователей. Вот в моменты записи/чтения в таблицу LOCKER транзакции просто доктор прописал — эти моменты столь кратковременны, что пессимистичная блокировка не видна для пользователей.

Иначе — бесконечные непонятки между пользователями.