|
|
|
Проблема с блокировкой??
|
|||
|---|---|---|---|
|
#18+
Люди, помогите разобраться с проблемой блокировки. Делаю SELECT * FROM Table1 WITH(UpdLock,RowLock) WHERE ID = Value1 Все как-будто замечательно, выбранные записи можно просматривать, но нельзя редактировать, а не попавшие в выборку через QA прекрасно редактирую. Но вот при открытом первом рекодсете, открываю второй точно такой же но с Value2. Выскакивает ошибка ожидания. Что не так??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2002, 12:15:03 |
|
||
|
Проблема с блокировкой??
|
|||
|---|---|---|---|
|
#18+
Как только начал редактировать запись с ID = Value1, тут же заблокировались и те записи, что рядом, как минимум на той же странице, так как при изменении происходят переупорядочивание данных и индексов и это не может не затронуть соседние записи. Точнее может, но при соблюдении кучи условий, реально которые практически невозможно соблюсти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2002, 13:31:28 |
|
||
|
Проблема с блокировкой??
|
|||
|---|---|---|---|
|
#18+
Да нет, все проще. Второй селект берет запись, накладывает на нее апдейт-лок, смотрит - там Value2 или нет, если нет, отпускает и идет дальше. Доходит до записи, к-ю держит первый селект. Value2 там или нет? А хрен его знает, т.к. наложить второй апдейт-лок он не может. Ну тогда он встает и ждет, бедолага, пока первый ее не отдаст. Варианты решений. 1) Не использовать во втором селекте updlock, чтобы он накладывал shared, совместимую с Upd, наложенной первым. 2) Создать индекс по ID, чтобы первый селект лочил не RIDы, а индексные ключи. 3) Подождать Юкона, где по слухам из буржуазной прессы должна появиться версионность записей. Но так ли это на самом деле, естественно, неизвестно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2002, 13:55:16 |
|
||
|
Проблема с блокировкой??
|
|||
|---|---|---|---|
|
#18+
А разве нихт RowLock не говорит, что надо блокировать только редактируемые строки? Тем более в моем конкретном случае, я вообще выбираю записи в рекордсет и сразу же делаю его отключенным (в VB через ADO). Непосредственно в базе записи меняются только при нажатии кнопки сохранить. Поэтому вообще ничего не понимаю :(( ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2002, 13:57:06 |
|
||
|
Проблема с блокировкой??
|
|||
|---|---|---|---|
|
#18+
Извините, что вмешиваюсь. Если Вы используете отсоединённый набор данных, у которого по определению LockType = adLockBatchOptimistic, зачем Вам ещё возможности по управлению блокировкой на сервере? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2002, 14:30:17 |
|
||
|
Проблема с блокировкой??
|
|||
|---|---|---|---|
|
#18+
2 Sharapp Зачем накладывать блокировку для отсоединенного набора данных? Кстати, а транзакцию предварительно не открываете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2002, 14:34:05 |
|
||
|
Проблема с блокировкой??
|
|||
|---|---|---|---|
|
#18+
Транзакцию конечно открываю, а блокировка для того чтобы другой бользователь не мог в это время открыть на редактирования туже запись. И во втором запросе не могу убрать UpdLock так, у всех пользователей одна программа. Попробую сейчас определить индексы и посмотрю что получится ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2002, 16:41:26 |
|
||
|
Проблема с блокировкой??
|
|||
|---|---|---|---|
|
#18+
Если доверить программистам строить дома, то первый залетевшый дятел разрушил бы всю цивилизацию. (с) не помню откуда ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2002, 16:57:55 |
|
||
|
Проблема с блокировкой??
|
|||
|---|---|---|---|
|
#18+
И установка ключа тоже не помогла: часть запесей могу выбрать, а часть нет, причем по какому принципу не понятно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2002, 17:22:18 |
|
||
|
Проблема с блокировкой??
|
|||
|---|---|---|---|
|
#18+
Sharapp, ты пытаешься воплотить в жизнь порочную практику. Поверь, наживешь себе гораздо больше проблеми, нежели их решишь. А если пользователь, открывший на редактирование запись, пошел попить чайку, а потом и вообще домой уехал? Ты полагаешь, другие юзвери к нему пойдут материться? Они к тебе пойдут! Я уже не говорю о том, что удержание на больших промежутках времени большого количества блокировок, да еще на уровне строки, способствует растранжириванию ресурсов SQL-сервера на блокировки. Как ты намерен решить проблему попытки открытия заблокированной записи другим пользователем? Думаешь, он сильно обрадуется, если перед тем, как выдать сообщение о том, что запись заблокирована, ему придется 1 минуту злобно дергать указателем мыши, который превратился в песочные часы? А попробуешь уменьшить таймаут, перестанут корректно работать некоторые процедуры, которых хотя и мало, и используются редко, но для работы которых требуется более 1 минуты... Нельзя завязывать иеханизм транзакций на сервере на визуальное отображение. Получишь страшный геморрой с взаимными блокировками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2002, 17:36:39 |
|
||
|
Проблема с блокировкой??
|
|||
|---|---|---|---|
|
#18+
А конкретно по затронутому вопросу дела обстоят так. Если ты внутри одной и той же транзакции заблокировал запись, то проблем быть не должно. Если в разных транзакциях (разный bath, разные сессии и т.д.), то это все равно, что к данным пытаются обратиться два разных пользователя - разницы никакой. При нескольких открытых Connection-ах одним приложением между скриптами, запускаемых в разных соединениях, могут возникнуть взаимные блокировки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2002, 17:41:26 |
|
||
|
Проблема с блокировкой??
|
|||
|---|---|---|---|
|
#18+
Дополнение. Ты подумай над одним вопросом - ЗАЧЕМ это тебе нужно. Если только затем, чтобы на экранах у пользователей высвечивалась гарантировано актуальная информация, синхронизированная с данными на сервере, то таким образом ты все равно эту проблему не решишь (точнее, решишь только одну ее часть, а другая все равно останется). Если один пользователь1 модифицировал запись, а пользователь2 открывал ее незадолго перед этим на просмотр, то после модификации пользователем1 содержимое записи на экране пользователя2 останется несоответствующим действительности. Для того, чтобы решить эту задачу методом блокирования записей, необходимо еще и при просмотре записей устанавливать ее тотальную блокировку. Одним словом, работать более одного юзера не смогут. А при таком подходе и проблемы с блокировками не стоит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2002, 17:48:00 |
|
||
|
Проблема с блокировкой??
|
|||
|---|---|---|---|
|
#18+
Good example of very bad programming style. Never do it again. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2002, 17:55:13 |
|
||
|
Проблема с блокировкой??
|
|||
|---|---|---|---|
|
#18+
Злые вы, уйду я от вас..........:)) Тогда скажите, как лучше организовать работу? С как лучше открывать данные на редактирования и как сохранять?? Научите новенького в этом деле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2002, 13:10:14 |
|
||
|
Проблема с блокировкой??
|
|||
|---|---|---|---|
|
#18+
ИМХО, самое разумное - обсудить с заказчиком действия при ситуации, когда пользователь(пишущий в базу) получит сообщение, что открытая им запись уже не актуальна. Например, при нулевых остатках это может быть и критично. А блокировки - исключительно на момент записи! У Garya сказано очень правильно! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2002, 13:33:20 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32052621&tid=1820055]: |
0ms |
get settings: |
8ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
43ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
70ms |
get tp. blocked users: |
2ms |
| others: | 230ms |
| total: | 394ms |

| 0 / 0 |
