|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
Всем доброго дня! Прошу сильно не пинать за вопросы :) Имеется проект Дельфи+firebird, который теперь переходит на многопользовательский режим, достался в наследство. В справочниках, диалоговые окна редактирования содержат по два FIBTransaction - один на чтение записей (read, nowait, rec_version, read_committed), второй на изменение (write, nowait, rec_version, read_committed). То есть при нажатии на кнопку "Изменить" срабатывает GET, выполняется процедура, вытаскиваются данные, затем CommitRetaining. Если менялись какие-либо данные, то срабатывает UPD, выполняется процедура и Commit. При таком раскладе как-то можно добиться блокировки записей? Счс она не работает, два приложения могут редактировать данные одновременно. Я попробовал поставить в процедуре GET "select for update with lock", но тогда возникает ошибка - "попытка изменить данные при чтении". Я сделал так - транзакцию в GET поменял на транзакцию UPD. То есть оба FIBStoredProc счс ссылаются на транзакцию UPD(write, nowait, rec_version, read_committed), и убрал CommitRetaining при чтении данных, теперь Commit срабатывает только при нажатии на кнопку ОК. И тогда блокировка срабатывает, т.е. если данная запись открыта в одном приложении, во втором при просмотре данной записи возникает ошибка. Я все сделал правильно? Может что-то упустил, или данный способ чреват подводными камнями? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 08:00 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
и что тогда делать, если пользователь просто решил просмотреть запись? Ведь просматривать он ее может сколь угодно долго ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 08:35 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
aidynchik...Счс она не работает, два приложения могут редактировать данные одновременно. Пусть. Абсолютно ничего страшного. В смысле: забей. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 10:54 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
ZeroMQ, ну как, один ввел одни данные, а второй - другие... потом же концов не найдут почему так произошло и то что вводил он, стало совсем другим ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 11:46 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
Hello, Zeromq! You wrote on 18 февраля 2016 г. 11:48:33: Zeromq> Пусть. Абсолютно ничего страшного. > В смысле: забей. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 11:48 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
Мимопроходящий, дельного совета не дадите? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 12:04 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
Hello, Aidynchik! You wrote on 18 февраля 2016 г. 12:05:58: Aidynchik> дельного совета не дадите? http://ibase.ru/devinfo/pslock.htm Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 12:06 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
Мимопроходящий, я читал это 100 раз, но так и не понял как сделать блокировку так, чтобы пользователь 2 не мог корректировать, но мог просматривать запись пока пользователь 1 ее редактирует (то есть нажал кнопку "Изменить" и набивает данные). Правильно ли я мыслю - мне надо иметь 3 FibStoredProc: 1 - это для просмотра записи, где будет селект без WITH LOCK, 2 - для просмотра записи, который будет запускаться по нажатию на кнопку "Изменить", где селект WITH LOCK, и 3 - это на сам апдейт. 1-ый будет именть транзакцию строго на чтение, 2 других - на редактирование. И мне придется иметь 2 варианта процедуры с селектами с WITH LOCK и без него? Неужто все так сложно? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 12:33 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
"просмотр" - это одна операция, "блокирование" и "редактирование" - другая. из этого и исходи. использовать ли SELECT ... WITH LOCK, или же "холостой" UPDATE - выбирай сам. если у тебя хитрозамороченных триггеров нет, можно обойтись одним UPDATE. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 12:40 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
Мимопроходящий, сорри, что тупо догоняю, но все же... счс у меня процедура просмотра данных одна (без LOCK соответственно) и вызывается она что при просмотре, что при редактировании. То есть мне надо разделить ее на 2 процедуры без LOCK - для просмотра, и с LOCK - для редактирования, правильно? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 12:46 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
я не понимаю зачем ты тривиальные действия обёртываешь процедурами. утрируя, на уровне GUI, блокировка должна выставляться (пытаться выставляться) при нажатии на кнопку "изменить". с процедурой, без процедуры - не имеет значения. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 12:57 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
aidynchikодин ввел одни данные, а второй - другие... потом же концов не найдут почему так произошло и то что вводил он, стало совсем другим Что значит "концов не найдут"? Станут кричать "кто сидел на моём стуле поменял мои данные?", второй пользователь-то и признается. Ты можешь автоматизировать этот процесс ведя журнал изменений документов. В чём проблема-то? Нет никакой разницы между редактированием ими данных одновременно или с разницей в полчаса. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 12:57 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
aidynchik, читай статью еще 100 раз. только не через слово, а подробно и медленно. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 12:58 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
Мимопроходящий, просто пытаюсь понять, как это технически реализовать :) всем спасибо за советы ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 13:14 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
aidynchikпросто пытаюсь понять, как это технически реализовать :) Протоколом изменений. Или проверкой не изменилась ли запись с начала её редактирования в GUI. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 13:16 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, можно еще и сообщениями обмениваться через firebird переводишь форму в режим редактирования - всем POST_EVENT про это и обратно что-то типа многопроцессорного кэша но сильно проще ( не нужны данные, а только сам факт редактирования ) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 13:49 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
aidynchikZeroMQ, ну как, один ввел одни данные, а второй - другие... потом же концов не найдут почему так произошло и то что вводил он, стало совсем другим А с блокировками - что изменится? :) ... Просто заворачивай логические операции изменений документа в одну транзакцию, и все. Или документ изменился/удалился, или нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 13:58 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
Arioch... переводишь форму в режим редактирования - всем POST_EVENT про это и обратно ... Открыл форму "на редактирование" и пошел обедать... ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 14:00 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
ZeroMQ, одинаковая проблема при любой схеме блокировок обед ещё фигня - а вот когда домой уходят вечером... тут либо не блокировать вообще, либо блокировать выбор, а я просто предложил вариант реализации блокировок ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 14:26 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
aidynchikпросто пытаюсь понять, как это технически реализовать :)Реализуй сначала логически, на бумаге. Если административно схема вменяема, то технически реализовать ее на файрберде можно. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2016, 16:09 |
|
блокирование записей в многопользовательском режиме
|
|||
---|---|---|---|
#18+
Например так можно: В таблицу добавляется поле Version, которое заполняется из генератора на создание и обновление записи. При чтении запоминаешь версию. Перед сохранением изменений ты открываешь транзакцию и первым делом читаешь значение версии. Если оно равно прошлому - значит изменений не было и можно смело писать. Если другое - стало быть кто-то уже успел изменить. Если прочитать ничего не удалось - значит запись удалили. В последних 2х случаях нужно, что-то сообщить об этом пользователю. :) Для того чтобы понять кто именно изменил, нужно ещё поле с id пользователя. Для того чтобы отследить когда изменили - поле с датой-временем изменения. Если нужны эти данные об удалённых записях - делаем доп. таблицу и заполняем в триггере after delete Можно что-то и более навороченное накрутить, но это по от задач зависит. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 08:35 |
|
|
start [/forum/topic.php?fid=40&msg=39173738&tid=1562328]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
34ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
others: | 259ms |
total: | 381ms |
0 / 0 |