|
|
|
Update & NoWait
|
|||
|---|---|---|---|
|
#18+
Есть такая ситуация. 1й клиент блокирует запись с помощью select ... for update. Другой пытается изменить ту же запись - естественно подвисает в ожидании commit от первого клента. Я так понимаю для того что бы второй клиент не висел в ожидании, нужно перед update поытаться заблокировать запись используя select ... for update. А можно ли сделать так, чтобы в такой ситуации Update возвращал ошибку 54, а не ожидал освобождения ресурса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 15:00:02 |
|
||
|
Update & NoWait
|
|||
|---|---|---|---|
|
#18+
select .... for update nowait; и ловить 54 ошибку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 15:03:14 |
|
||
|
Update & NoWait
|
|||
|---|---|---|---|
|
#18+
используй select ... for update NO WAIT ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 15:04:47 |
|
||
|
Update & NoWait
|
|||
|---|---|---|---|
|
#18+
А если другой клиент удалил запись? Как ловить? Оракл ошибку не возвращает:( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 15:48:06 |
|
||
|
Update & NoWait
|
|||
|---|---|---|---|
|
#18+
очень просто посмотреть на кол-во обработанных записей, если их 0 то кто-то что-то удалил или изменил ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 17:03:15 |
|
||
|
Update & NoWait
|
|||
|---|---|---|---|
|
#18+
А вот другой изыск. Запись была прочитана, затем чего-то считалось. В это время другой клиент изменил прочитанную запись. Может ли первый клиент определить факт этого изменения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 17:34:38 |
|
||
|
Update & NoWait
|
|||
|---|---|---|---|
|
#18+
Слушай, ну какие тут изыски? Один залочил на апдейт\удаление. Другой при попытке залочить с опцией nowait получит сообщение- отбой на любые изменения, и пойдет курить :) Придет, сделает рефреш, или это произойдет по таймеру...или не проникся я? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 17:41:36 |
|
||
|
Update & NoWait
|
|||
|---|---|---|---|
|
#18+
2 Ivanoff Однако этот совсем другой изыск, и решается он другими средствами. Например timestamp в записи и сравнение в тригере перед Update: ту ли запись правил юзер, или она успела поменяться пока он правил. У меня на этот случай в записи храниться двухбайтовая циклическая "версия" записи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 18:56:25 |
|
||
|
Update & NoWait
|
|||
|---|---|---|---|
|
#18+
2 Duce Не, не проникся, все гораздо запущенее:) 2 Поплюев Алексей К сожалению (к счастью?) мне такие сложности не грозят. Это не тот случай. Но если используется подобная техника - значит я верно представлял себе весь процесс. Всем спасибо. Всю необходимую информацию я получил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2003, 08:43:57 |
|
||
|
Update & NoWait
|
|||
|---|---|---|---|
|
#18+
2Ivanoff: ситуация простая первый юзер прочитал запись, потом 5 минут ее другим оператором обсчитывает и хочет узнать не поменялась ли она за это время возьми и считай ее заново если у нее другие значения или ее нет значит поменялась ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2003, 11:44:40 |
|
||
|
|
start [/forum/topic.php?fid=52&msg=32189533&tid=1989845]: |
0ms |
get settings: |
23ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
188ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
2ms |
| others: | 419ms |
| total: | 701ms |
| 0 / 0 |
