Как избавиться от длительной блокировки записи?

← →
guest_Dmitry (2004-07-26 18:32) [0]

Столкнулся с такой проблемой: пользователь открыл запись в базе на редактирование и ушел покурить, кофе попить, либо внес изменения и забыл запостить датасет. В результате запись на длительное время остается заблокированная. Кто как с этим борется, подскажите пожалуйста.

← →
Игорь Шевченко © (2004-07-26 18:34) [1]

> пользователь открыл запись в базе на редактирование

Это как ?

P.S. А база какая (СУБД) ?

← →
ИдиотЪ (2004-07-26 18:35) [2]

сделай тайм-аут, после чего сними блокировку
зависит от задачи, так как прочитать ее можно ведь

← →
guest_Dmitry (2004-07-26 18:36) [3]

Игорь Шевченко © (26.07.04 18:34) [1]

СУБД Interbase 6.0

ИдиотЪ (26.07.04 18:35) [2]

от чего считать начинать?

← →
Ega23 © (2004-07-26 18:38) [4]

И не злоупотребляй высоким Isolation Level

← →
guest_Dmitry (2004-07-26 18:40) [5]

Ega23 © (26.07.04 18:38) [4]

стоит ReadCommited

← →
ИдиотЪ (2004-07-26 18:41) [6]

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

← →
Ega23 © (2004-07-26 18:43) [7]

Вот именно этим мне всегда TTable не нравился...

← →
ИдиотЪ (2004-07-26 18:45) [8]

Ega23 ©
забить на TTable
взять родное и приспособленное что-нибудь

← →
Ega23 © (2004-07-26 18:46) [9]

взять родное и приспособленное что-нибудь

А я им и не пользуюсь, потому что он мне не нравиться

← →
guest_Dmitry (2004-07-26 18:47) [10]

ИдиотЪ (26.07.04 18:41) [6]

записи то постятся по нажатии кнопки пользователем. т.е. вы предлагаете вместо dbedit-ов пользоваться простыми edit-ами, например, и по нажатии кнопки записывать все изменения в базу?

Ega23 © (26.07.04 18:43) [7]
ИдиотЪ (26.07.04 18:45) [8]

использую fibDataSet

← →
ИдиотЪ (2004-07-26 18:47) [11]

а еще TTable сортировать в памяти бы научился,
ну нафига мне сервер мучить каждый раз?
ClientDataSet гораздо лучше себя ведет

← →
ИдиотЪ (2004-07-26 18:49) [12]

guest_Dmitry
используй кешированный способ записи в базу

← →
guest_Dmitry (2004-07-26 18:50) [13]

ИдиотЪ (26.07.04 18:47) [11]

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

← →
Ega23 © (2004-07-26 18:51) [14]

записи то постятся по нажатии кнопки пользователем. т.е. вы предлагаете вместо dbedit-ов пользоваться простыми edit-ами, например, и по нажатии кнопки записывать все изменения в базу?

Лично я всегда именно так делаю. А проверить на существование идентичной записи ты можешь в момент "накатки" в базу. А ещё лучше - создаёшь таблицу блокировок, и блокируешь ЗАПИСЬ, а не всю таблицу целиком.

← →
guest_Dmitry (2004-07-26 18:55) [15]

Ega23 © (26.07.04 18:51) [14]

т.е. каждый раз проверять существует ли запись вообще и в каком виде? до того, как пользователь нажмет "сохранить" запись может очень сильно измениться.....

по поводу:
>А ещё лучше - создаёшь таблицу блокировок, и блокируешь ЗАПИСЬ, >а не всю таблицу целиком
можно поподробнее применительно к Interbase?

← →
Ega23 © (2004-07-26 19:11) [16]

можно поподробнее применительно к Interbase?

C Interbase знаком плохо, поэтому пишу для MS SQL. Здесь идея важна, всё остальное вторично:
create table Blocks ( UNID int, PersID int, WorkCod int, BlockNam varchar(16), BlockID int)
PersID - ID оператора, ктоторый работает (если такие у тебя есть)
WorkCod - ID раб.станции, с которой работает оператор
BlockNam - Некое имя для операций, допустим "GOODS" - для товаров, "SHOPS" - для магазинов и т.п.
BlockID - собственно ID той записи, которую блокируешь.

Оператор перед началом редактирования проверяет таблицк блокировки. Если данная запись заблокирована кем-то другим - откат, если нет - вперёд.
Один оператор открыл форму для редактирования - данные по данной записи ему передались "грязным чтением", но при этом в таблицу блокировок добавилась соответствующая запись.
Оператор внёс изменения в базу - блокировка убралась.

Вот в таком вот духе.

← →
guest_Dmitry (2004-07-26 19:18) [17]

Так а что это изменит? Только то, что можно будет увидеть кто заблокировал запись?

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

и

>Оператор внёс изменения в базу - блокировка убралась.

оператор может отвлечься на какое-то время, а блокировка то висит....

← →
Сергей Суровцев © (2004-07-26 19:18) [18]

Лучше всего базу вообще сразу отпускать. Пусть клиент у себя редактирует сколько влезет, хоть повиснет, а воткогда кнопочкой подтвердил изменения, то тогда и в базу. И база целее будет и нервы.

← →
Ega23 © (2004-07-26 19:20) [19]

оператор может отвлечься на какое-то время, а блокировка то висит....

Да, но висит блокировка только одной записи, а не всей таблицы. Другие-то записи редактировать можно!

← →
Ega23 © (2004-07-26 19:21) [20]

Сергей Суровцев © (26.07.04 19:18) [18]

Тоже вариант. Но в моём проекте совершенно неприемлем, ибо именно НУЖНО показывать оператору КЕМ заблокирована запись.

← →
guest_Dmitry (2004-07-26 19:25) [21]

Сергей Суровцев © (26.07.04 19:18) [18]

Т.е. включать CachedUpdates?

Была мысль перехватывать нажатие клавиш и движение мыши, и если оных не происходило какое-то время, то делать откат. Но как такое реализовать, если программа, например, неактивна?

← →
guest_Dmitry (2004-07-26 19:27) [22]

Ega23 © (26.07.04 19:20) [19]

Так в том то и оно, что нужно сформировать документ на какого-то партнера, а эта запись в справочнике как раз заблокирована.

← →
guest_Dmitry (2004-07-26 19:29) [23]

в продолжение к guest_Dmitry (26.07.04 19:27) [22]

и чем больше пользователей, том встречаться ситуация стала чаще..

← →
Esu © (2004-07-26 19:52) [24]

Мне таблица блокировок больше нравится, а то поменял, сохранил, пошел кофе пить. А тут кто-то другой то же самое сделал :)

← →
guest_Dmitry (2004-07-26 19:55) [25]

Попробую вопрос тогда по другому сформулировать: как отловить бездействие пользователя в течении какого-то времени?

← →
Anatoly Podgoretsky © (2004-07-26 20:04) [26]

guest_Dmitry (26.07.04 18:32)
Лишением премии

← →
guest_Dmitry (2004-07-26 20:09) [27]

Для фирмы к тому же экономически выгодно, не думай что я шучу

← →
ИдиотЪ (2004-07-27 09:22) [29]

Ega23 ©
насчет блокировок я не совсем понял твою идею
Как узнать, что блокировка жива ? Т.е. сеанс не отвалился, а то будет до скончания века висеть )

В многопользовательских базах в идеале не должно быть никаких блокировок.
Блокировкам смерть!

> стоит ReadCommited

этот уровень не держит запись

← →
ИдиотЪ (2004-07-27 10:51) [32]

Мужики, че вы спорите? Какие нафиг блокировки, зачем? Сервак и так не даст изменить заблокированную им самим запись. Единственное что надо сделать - реакцию на исключительную ситуацию и правильная работа с транзакциями. И нефига давать юзеру возможность редактировать вручную через ДБ-компоненты, особенно в реально многопользовательских базах.

2guest_Dmitry (26.07.04 18:32)
>пользователь открыл запись в базе на редактирование и ушел покурить
Это проблема не пользователя а программера.

мне известны два варианта решения этой проблемы,
первый: select for update (так в oracle) но в твоей СУБД должна быть аналогичная фишка, которая не дает менять _выбранные_ записи другим транзакциям. второй вариант, непосредственно перед update"ом (после перекура), делать select по всем полям (хотя достаточно только по обновляемым), дабы убедиться, что за перекур, твою запись никто не тронул. И при наличии их, update+commit, иначе exception "Минздрав предупреждал"

имхо, другие варианты (если они есть) не правильные =)

← →
ИдиотЪ (2004-07-27 11:15) [35]

1. IB не блокировочник, а версионник.
2. Блокировку можно сымитировать.
3. Если этого специально не делать, то можно идти пить кофе/пиво.
4. Пишущая тр-ия короткая и стартует в момент нажатия [Ok]

Как избавиться от длительной блокировки записи? Найти похожие ветки