Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Есть следующая тема. Имеется некоторая таблица Tbl: ParentID, Fld1,...,Fldn Например, со следующими значениями: 1 , v11,...,v1n 2 , v21,...,v2n 2 , v31,...,v3n 3 , v41,...,v4n 3 , v51,...,v5n ... Начинаем транзакцию. Создаем временную таблицу Tmp (RowNumber, ParentID, Fld1,...,Fldn) Заполняем ее: INSERT INTO tmp SELECT ROW_NUMBER () OVER (), Tbl.* FROM Tbl WHERE ParentID = 2 (2 - взято для примера) Далее пользователь на свое усмотрение изголяется над этой временной таблицей, т.е. добавляет, изменяет, удаляет. В завершение транзакции следует залить Tmp в Tbl с помощью MERGE по ParentID и RowNumber. После этого с легким сердцем сделать COMMIT. Вопрос, собственно не в механизме - здесь все ясно. Вопрос в следующем: как сделать так, чтобы запрос "SELECT ROW_NUMBER () OVER (), Tbl.* FROM Tbl WHERE ParentID = 2" возвращал по любому одинаковый результат, как в начале транзакции, так и непосредственно в момент слияния, т.е. задать явно или неявно такую блокировочку, которая не даст другому юзеру в таблице Tbl: 1. изменить записи с ParentID = 2 2. удалить записи с ParentID = 2 3. добавить записи с ParentID = 2 и при этом позволит делать все что угодно с записями, где ParentID <> 2 ? С изменением и удалением все ясно (помогает FOR UPDATE), а вот что делать с добавлением непонятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 11:26 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
А зачем??? У тебя на Tbl нет что-ли первичного ключа??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 11:29 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Есть ключ - нет ключа, это, я вам скажу, отношения к делу не имеет. Вопрос был о блокировках. Зачем? - Надо... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 11:35 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Надо - святое дело. Тогда вам в оффициальную документацию, на Information Center, ссылок здесь много давали. Потому как доку читать тоже НАДО. Зачем? Так НАДО же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 11:52 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
другие пользователи должны иметь доступ к этим данным? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 11:53 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Ну то, что написано в документации я почитал до того как стал вам задавать вопросы... Конкретнее, есть что нибудь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 11:55 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
To Nikolay Kulikov Да доступ должен быть, но только на чтение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 11:58 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Читал??? "Не верю!" (с) Станиславский. Просмотрел - жругое дело ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 11:59 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
To ggv Просьба не хамить. Если вы читали доки основательнее - подскажите мне убогому, что надо делать. А трепаться по пусту каждый мастер... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 12:05 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Единственное что приходит на ум - писать в некое поле в таблице Tbl некоторое значение ассоциирующееся с текущей сессией (при оспобождении - обNULLяем). Ну, и затем проверять, существует такая сессия или нет - если существует - то можно знач удалять добавлять и проч. Кстати, to Nikolay Kulikov, собираются ли IBM сделать триггеры на Connect/Disconnect ? Потомошто надо иногда... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 12:06 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Формальный ответ - задать уровень изоляции Repeatable Read http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/admin/c0007870.htm ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 12:10 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Да весь раздел "Concurrency, isolation levels, and locking" надо читать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 12:21 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
To Victor Metelitsa С Repeatable Read есть проблемы. Задавать этот уровень изоляции для всей БД низя ибо слишком жестко. А если пишешь в select ... with rr - блокируются и все отсальные записи (где ParentID иной), хотя таблица была создана с LOCKSIZE ROW. To gardenman Круто загнуто... Но все же надо попробовать воспользоваться стандартными механизмами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 12:21 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Ничего крутого. Обыкновенная логическая блокировка. Можно механизм даже улучшить. Способов - много. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 12:27 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Уровень изоляции задаётся не для "всей БД", а для коннекта. Да, RR - это очень жёстко, но официальный ответ именно такой, коли вам надо, чтобы записи не вставились. Попробуйте для parentId создать индекс - это может помочь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 12:31 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Индекс на ParentID имеется. А насчет уровня изоляции на сессию - не пробовал - надо посмотреть... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 12:49 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Использовать RR чтобы обеспечить непротиворечивость UI - это слишком. ИМХО. Причем это platform independent. По хорошему нужно смотреть на бизнеслогику + юзать set timeout no wait. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 12:57 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Ну, или перечислить в индексе все колонки, начиная с RowNumber: create index ... (RowNumber, ParentID, Fld1,...,Fldn) Короче, если оптимизатор решит, что этим индексом нужно пользоваться, то в нашем случае на уровне изоляции RR дело будет в шляпе (чтобы блокировались не отдельные строчки, а предикат). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 12:58 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Интересен также вариант с MDC по parentId и LOCKSIZE BLOCKINSERT. Но, наверное, в нашем случае это будет чрезвычайно неэффективно по дисковому пространству, с неизбежными следствиями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 13:09 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Кстати если скомбинировать решение от gardenmana и select from update то получится неплохо... что-то типа Код: plaintext 1. 2. А когда делаем МЕRGE обнудяем app_id Опять же вопрос зависит от того нужно другим приложениям доступ к этим таблица м и какой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 13:14 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaНу, или перечислить в индексе все колонки, начиная с RowNumber: create index ... (RowNumber, ParentID, Fld1,...,Fldn) Короче, если оптимизатор решит, что этим индексом нужно пользоваться, то в нашем случае на уровне изоляции RR дело будет в шляпе (чтобы блокировались не отдельные строчки, а предикат). Глюк. Имелось в виду - с ParentID. create index ... tbl(ParentID, Fld1,...,Fldn) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 13:23 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Nikolay KulikovКстати если скомбинировать решение от gardenmana и select from update то получится неплохо... Не получится. Задумайтесь над вариантом, когда данного parentId в tbl нет и два юзера одновременно хотят вставить записи. Если же записи есть, то SELECT FOR UPDATE делает ненужным присваивание app_id. Если уж на то пошло, записям, соотвествующим parentId (даже если это множество пусто), должно соответствовать некое ключевое id в некоей таблице, и можно выполнять select ... from некаятаблица where id=? for update Использование ROW_NUMBER () OVER (), да, "очаровательно". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 13:33 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Когда они хотят его вставить это момент MERGE на нем и выставлять нужный уровень изоляции, а не держать блокировки все время... Задача не понятна, возможно есть другие условия решения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 14:54 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
а задачу и нельзя нам понять. Ясно только, что "надо". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 15:00 |
|
||
|
О блокировках
|
|||
|---|---|---|---|
|
#18+
Редактируем дерево и пытаемся блокировать узел от вмешательства других пользователей. Логичнее мне кажется блокировать сам узел, а не его потомков. Быть может, app_id всё же стоит добавить. При этом, когда читаем список узлов, читаем select... with ur, и где app_id не пустой, подсвечиваем в GUI красным цветом. При редактировании делаем сперва select ... for update, установив lockwait на 0 (чтобы отбрасывало сразу с ошибкой, если уже редактирует кто-то другой). Если какая-то программа отвалилась по ошибке, rollback вернёт app_id на место - в пустое состояние. Ещё может иметь смысл поле "версия", увеличивающееся на 1 после каждого успешного редактирования, или timestamp этого успешного редактирования. Для чего нужно копировать данные (потомки узла) во временную таблицу, это загадка. Наверное, Smalltalk меня слишком избаловал, а вот бедным Java/Delphi/VS-программёрам приходится так мучаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2006, 15:57 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=33590083&tid=1605469]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
44ms |
get topic data: |
11ms |
get forum data: |
6ms |
get page messages: |
67ms |
get tp. blocked users: |
1ms |
| others: | 229ms |
| total: | 389ms |

| 0 / 0 |
