ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / deadlock при update записи
49 сообщений из 49, показаны все 2 страниц
  все  
deadlock при update записи
    #38479684
Павел Ишенин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Ишенин
Участник
Перерыл все интернеты, но никак не могу понять в чем может быть причина deadlock.
...
Рейтинг: 0 / 0
27.11.2013, 12:48:47
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38479694
miwaonline
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miwaonline
Участник
Павел Ишенин,

Надо срочно менять интернеты. На вот такие , например. Ну а если взять вот такие , то вообще красота.
...
Рейтинг: 0 / 0
27.11.2013, 12:51:42
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38479707
Павел Ишенин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Ишенин
Участник
Имею след. запрос:

UPDATE OR INSERT INTO USERS_LOG (USER_ID, LAST_ACTIVE, IP_ADDRESS) VALUES ('6F175349428A6A4A93E8B1D65B9BEA78', CURRENT_TIMESTAMP, '127.0.0.1')

Он выполняется каждым клиентом (web-броузер через Ajax) раз в минуту. Иногда этот запрос создает deadlock. Таблица не имеет никаких триггеров.

Все транзацкии read write lock timeout 10
...
Рейтинг: 0 / 0
27.11.2013, 12:55:42
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38479732
Павел Ишенин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Ишенин
Участник
miwaonlineНадо срочно менять интернеты. На вот такие , например. Ну а если взять вот такие , то вообще красота.

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

Эту статью я читал. Ситуация происходит следующая:

1. Транзакция 1 (set transaction read write wait timeout 10) стартует и начинает выполнять запрос на update конкретной записи в таблице.
2. Видимо в этот же самый момент стартует Транзакция 2 с теме же параметрами и выполняет тот же самый запрос.
3. Транзакция 1 успешно завершается.
4. Транзакция 2 ничего не ждя выдает: "General error: -913 deadlock update conflicts with concurrent update concurrent transaction number is ..."

Но транзакции же wait, а значит, по моему мнению, транзакция 2 должна дождаться комита первой и выполнить запрос без ошибок.
...
Рейтинг: 0 / 0
27.11.2013, 13:05:38
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38479833
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Павел Ишенинпо моему мнению, транзакция 2 должна дождаться комита первой и
выполнить запрос без ошибок.
Твоё мнение совпадает с мнением Ларри Эллисона, но отнюдь не Джима Старки. Поэтому иди-ка
с ним на Оракул.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.11.2013, 13:49:31
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38479867
Fr0sT-Brutal
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Fr0sT-Brutal
Гость
Почему у двух разных клиентов одинаковые ID (иначе не было бы concurrent update)? Если для каждого будет уникальный, то проблема исчезнет.
...
Рейтинг: 0 / 0
27.11.2013, 14:04:17
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38479934
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
Такой длинный идентификатор клиента и не уникальный... Галактика в опасности? или консерватория?

Напомнил анекдот про ОченьДлинныйИдентификатор1,ОченьДлинныйИдентификатор2...

Fr0sT-BrutalЕсли для каждого будет уникальный, то проблема исчезнет.А если еще и не адейтить, то ее не будет "бай дизайн". Даже Таблоиду не удалось нагнуть сервер на конкурентных инсертах. :)
...
Рейтинг: 0 / 0
27.11.2013, 14:29:53
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38479941
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Ivan_PisarevskyДаже Таблоиду не удалось нагнуть сервер на конкурентных инсертах. :)

Николаю удалось.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.11.2013, 14:34:10
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38479946
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
Dimitry SibiryakovНиколаю удалось.Павел Ишенинвыполняется каждым клиентом раз в минуту.Явно не с такой частотой шли инсерты.
...
Рейтинг: 0 / 0
27.11.2013, 14:38:13
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38479949
Павел Ишенин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Ишенин
Участник
Fr0sT-BrutalПочему у двух разных клиентов одинаковые ID (иначе не было бы concurrent update)? Если для каждого будет уникальный, то проблема исчезнет.

Так клиенты же одинаковые. Это web, и как следствие могут быть где-то задержки. Например, при коннекте из Норильска (чаще всего именно у них выскакивает этот deadlock) через их спутниковую связь. Таким образом, ajax запрос где-то задержался и нам на сервер вместо одного через минуту сразу прилетело 2.

В принципе ничего ужасного в этих deadlock нет, но хотелось бы избавиться если это возможно.
...
Рейтинг: 0 / 0
27.11.2013, 14:38:46
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38479968
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
Павел Ишенинхотелось бы избавиться если это возможно.инсерт "наше фсё". Опционально можно зачистить во время периодических регламентных работ.
...
Рейтинг: 0 / 0
27.11.2013, 14:48:09
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38479975
Павел Ишенин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Ишенин
Участник
Dimitry SibiryakovПавел Ишенинпо моему мнению, транзакция 2 должна дождаться комита первой и
выполнить запрос без ошибок.
Твоё мнение совпадает с мнением Ларри Эллисона, но отнюдь не Джима Старки. Поэтому иди-ка
с ним на Оракул.


Спасибо Дмитрий. Мы используем как Oracle, так и Firebird, но первый раз столкнулись с разработкой под web с Firebird. Хотели решить проблему средствами СУБД, но если таким образом победить deadlock не получится, то будем решать с других сторон.

Возвращаясь к теме, мы проводили эксперименты блокируя запись из IBExpert, и в этом случае получали ожидаемый результат - firebird ждал положенные 10 (или около того) секунд и возвращал ошибку "lock timeout" (или что-то вроде), а не "deadlock". Отсюда и причина исходного вопроса о причине deadlock.
...
Рейтинг: 0 / 0
27.11.2013, 14:49:54
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38479985
Павел Ишенин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Ишенин
Участник
Ivan_PisarevskyПавел Ишенинхотелось бы избавиться если это возможно.инсерт "наше фсё". Опционально можно зачистить во время периодических регламентных работ.

Записанная информация используется для отображения активности пользователя в web-приложении. Если использовать только insert, то усложнится запрос select, а как следствие и время извлечения информации из СУБД. А скорость времени выполнения запросов в web-приложениях критически важна.
...
Рейтинг: 0 / 0
27.11.2013, 14:54:30
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38479986
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Павел ИшенинОтсюда и причина исходного вопроса о причине deadlock.

Нет в исходном вопросе никакого "deadlock". Есть "update conflict", который возникает
всегда , когда параллельные транзакции изменяют одну и ту же запись. Вне зависимости
от параметра wait.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.11.2013, 14:55:10
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38479991
pastor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pastor
Участник
Павел ИшенинDimitry Sibiryakovпропущено...

Твоё мнение совпадает с мнением Ларри Эллисона, но отнюдь не Джима Старки. Поэтому иди-ка
с ним на Оракул.


Спасибо Дмитрий. Мы используем как Oracle, так и Firebird, но первый раз столкнулись с разработкой под web с Firebird. Хотели решить проблему средствами СУБД, но если таким образом победить deadlock не получится, то будем решать с других сторон.

Возвращаясь к теме, мы проводили эксперименты блокируя запись из IBExpert, и в этом случае получали ожидаемый результат - firebird ждал положенные 10 (или около того) секунд и возвращал ошибку "lock timeout" (или что-то вроде), а не "deadlock". Отсюда и причина исходного вопроса о причине deadlock.

в примере, с которого все началось, запись НЕ БЛОКИРОВАНА
...
Рейтинг: 0 / 0
27.11.2013, 14:56:23
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38479993
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
Павел Ишенинто усложнится запрос select,Правда? ну если написание select first 1... order by last_active desc вместо select ...
Павел Ишенина как следствие и время извлечения информации из СУБДровно одно индексное чтение в обоих случаях (если дизайн базы не с похмела делался).
...
Рейтинг: 0 / 0
27.11.2013, 14:57:57
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38479997
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
Павел ИшенинЕсли использовать только insertто не будет версий->мусора, который гарантированно появится при апдейтах.
...
Рейтинг: 0 / 0
27.11.2013, 15:00:08
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480007
Павел Ишенин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Ишенин
Участник
Dimitry SibiryakovПавел ИшенинОтсюда и причина исходного вопроса о причине deadlock.

Нет в исходном вопросе никакого "deadlock". Есть "update conflict", который возникает
всегда , когда параллельные транзакции изменяют одну и ту же запись. Вне зависимости
от параметра wait.


deadlock есть в сообщении об ошибке с сервера. В любом случае, спасибо. Из вашего сообщения я понял, что эту ошибку никак не исправить средствами СУБД, а следовательно нужно искать решения на стороне web-приложения.
...
Рейтинг: 0 / 0
27.11.2013, 15:02:33
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480014
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Павел Ишенинскорость времени выполнения запросов в web-приложениях критически
важна.
Нет, если не баловаться таймаутом выполнения скриптов или использовать вменяемые языки
программирования вместо них.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.11.2013, 15:04:14
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480019
Фотография arni
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
arni
Участник
Павел Ишенин
Код: sql
1.
UPDATE OR INSERT INTO USERS_LOG (USER_ID, LAST_ACTIVE, IP_ADDRESS) VALUES ('6F175349428A6A4A93E8B1D65B9BEA78', CURRENT_TIMESTAMP, '127.0.0.1')

а если обновлять, только если таймстемп уже малость протух (более одной минуты)? Если такого рода запросы сыпятся без остановки, то возможно проредить update не помешает, чем снизить конкурентность.
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
execute block(
  USER_ID type of column USERS_LOG.USER_ID = :USER_ID)
as
begin
  if (exists(select 1 from USERS_LOG where USER_ID=:USER_ID)) then
    update USERS_LOG
       set LAST_ACTIVE = CURRENT_TIMESTAMP, 
           IP_ADDRESS = '127.0.0.1'
     where USER_ID=:USER_ID
       and datediff(minute from LAST_ACTIVE to CURRENT_TIMESTAMP)>1; --обновляем c некоторой гранулярностью
  else
    INSERT INTO USERS_LOG 
      (USER_ID, LAST_ACTIVE, IP_ADDRESS) 
    VALUES 
      (:USER_ID, CURRENT_TIMESTAMP, '127.0.0.1');
end


ну и заменить транзакцию на nowait
...
Рейтинг: 0 / 0
27.11.2013, 15:05:07
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480026
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Павел Ишенинdeadlock есть в сообщении об ошибке с сервера.
Это старый известный недостаток данного сообщения: в "братскую могилу" со строкой
"deadlock" собраны все конфликты. Именно поэтому читая сообщение об ошибке ни в коем
случае нельзя останавливаться на его первой строке . По-настоящему полезная информация
приводится в последних строках.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.11.2013, 15:08:41
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480028
Павел Ишенин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Ишенин
Участник
Ivan_PisarevskyПавел ИшенинЕсли использовать только insertто не будет версий->мусора, который гарантированно появится при апдейтах.

Мусор в этом случае появится в самой таблице + дополнительный индекс.
...
Рейтинг: 0 / 0
27.11.2013, 15:09:32
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480054
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
Павел ИшенинИногда этот запрос создает deadlock.А почему это проблема? Раз дэдлок, значит запись уже есть, сам же пользователь ее и апдейтит, чего ее апдейтить повторно? поймал, обработал, юзеру можно и не показывать.
...
Рейтинг: 0 / 0
27.11.2013, 15:19:26
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480161
Павел Ишенин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Ишенин
Участник
Ivan_PisarevskyПавел ИшенинИногда этот запрос создает deadlock.А почему это проблема? Раз дэдлок, значит запись уже есть, сам же пользователь ее и апдейтит, чего ее апдейтить повторно? поймал, обработал, юзеру можно и не показывать.

Юзеру эта ошибка не показывается.

Ребята, большое спасибо за разъяснение причины ошибки. Теперь, когда я понимаю причину, я найду подходящее решение. Тему можно закрывать.
...
Рейтинг: 0 / 0
27.11.2013, 16:05:57
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480228
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Ivan_PisarevskyДаже Таблоиду не удалось нагнуть сервер на конкурентных инсертах. :) чё-чё ?
...
Рейтинг: 0 / 0
27.11.2013, 16:40:30
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480265
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид чё-чё ?
дык инсерты там вообще не причем
...
Рейтинг: 0 / 0
27.11.2013, 16:57:21
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480272
Fr0sT-Brutal
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Fr0sT-Brutal
Гость
Самый безопасный метод - это одни инсерты без апдейтов, но он же наиболее неудобный. В текущей ситуации порекомендовал бы сделать транзакции no wait и ловить исключения concurrent update, в случае ошибки повторять запрос либо идти на выход.
...
Рейтинг: 0 / 0
27.11.2013, 17:04:29
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480428
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrдык инсерты там вообще не причемА, нашёл. Это в личку ты прислал, 12-ноя-2013 19:51 (тема письма: "Нагрузочный тест: lock conflict'ы в базе, в которую идут только COMMIT'ы ").
Но из того объяснения я так и не понял, почему эта ошибку так трудно было воспроизвести. И почему вообще никто про неё ничего не говорил с 2000 %-)
...
Рейтинг: 0 / 0
27.11.2013, 18:38:05
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480434
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
причем тут личка, в трекере есть описание ошибки, там есть хоть слово про инсерты? Или думаешь я там специально туман напускаю, чтобы никто не догадался? :-)
...
Рейтинг: 0 / 0
27.11.2013, 18:40:54
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480481
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrв трекере есть описание ошибки, там есть хоть слово про инсерты? http://tracker.firebirdsql.org/browse/CORE-4265 Under high concurrent load isc_attach_database() may return isc_lock_conflict error:

Statement failed, SQLSTATE = 40001
lock conflict on no wait transaction

without any obvious reasons . This happens only when a number of connections are being established at the same time .1) without any obvious reasons - они и сейчас, после фикса, не очевидные ?
2) are being established at the same time - я перевожу как: "устанавливаются в ОДНО И ТО ЖЕ время". Но в том тесте все новые коннекты шли с задержкой, там вызов паузы был между каждым N-м и (N+1)-м окном. И сообщение "lock conflict error" вылезало далеко не сразу после начала теста.

И я в итоге так и не понимаю до сих пор: оно вообще с чем было связано-то ?
...
Рейтинг: 0 / 0
27.11.2013, 18:59:54
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480551
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидони и сейчас, после фикса, не очевидные ?
это описание с т.з. наблюдателя. Причины есс-но стали понятны при исправлении.

Таблоидя перевожу как: "устанавливаются в ОДНО И ТО ЖЕ время". Но в том тесте все новые коннекты шли с задержкой, там вызов паузы был между каждым N-м и (N+1)-м окном. И сообщение "lock conflict error" вылезало далеко не сразу после начала теста.
это не означает, что через N минут работы два окна не могли пытаться приконнектиться в ОДНО И ТО ЖЕ время. Что и приводило к ошибке, если они выполняли один и тот же код (весьма короткий, а потому неуловимый) одновременно.
...
Рейтинг: 0 / 0
27.11.2013, 19:36:07
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480558
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrЧто и приводило к ошибке, если они выполняли один и тот же код (весьма короткий, а потому неуловимый) одновременно.Теперь понятно. Спасибо.
...
Рейтинг: 0 / 0
27.11.2013, 19:40:56
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480559
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
PS. да, в той версии действительно были частые переконнекты.
...
Рейтинг: 0 / 0
27.11.2013, 19:41:38
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480921
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Dimitry Sibiryakov,
я так понимаю, Оракл при update conflict и wait, в отличие от IB/FB, тупо переписывает изменения, на которые он "натолкнулся"? И это радует Павла Ишенина? Я удивлен. Зачем тогда wait?
...
Рейтинг: 0 / 0
28.11.2013, 00:33:18
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38480928
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
kdvя так понимаю, Оракл при update conflict и wait, в отличие от IB/FB, тупо
переписывает изменения, на которые он "натолкнулся"? И это радует Павла Ишенина? Я
удивлен. Зачем тогда wait?
Это чуть-чуть иначе.
Во-первых, у Оракула принципиально нет no wait.
Во-вторых, он при конфликте не "переписывает изменения", а откатывает запрос и повторяет
его целиком.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
28.11.2013, 00:42:09
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38481005
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Dimitry Sibiryakov,

ну и нафиг нам такой Оракл тут нужен... Перезапись чужих изменений без понимания, что это за изменения - зло.
...
Рейтинг: 0 / 0
28.11.2013, 03:04:29
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38481011
Павел Ишенин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Ишенин
Участник
kdvDimitry Sibiryakov,

ну и нафиг нам такой Оракл тут нужен... Перезапись чужих изменений без понимания, что это за изменения - зло.

А если с пониманием, что это повторный ajax request догнал первый и они оба прилетели на сервер одновременно? В текущей логике приложения других подобных ситуаций быть не может.
...
Рейтинг: 0 / 0
28.11.2013, 03:32:42
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38481047
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Павел Ишенин,

если конфликты в принципе допустимы, но хочется уменьшить их число в таких ситуациях - рассмотри вариант с режимом изоляции read_committed no_record_version
...
Рейтинг: 0 / 0
28.11.2013, 07:31:49
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38481121
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NickDee
Участник
kdvDimitry Sibiryakov,
я так понимаю, Оракл при update conflict и wait, в отличие от IB/FB, тупо переписывает изменения, на которые он "натолкнулся"? И это радует Павла Ишенина? Я удивлен. Зачем тогда wait?
А если commit первой транзакции произошёл одну наносекунду назад, то уже всё ok? Мы (вторая транзакция) должны радоваться что не случилось конфликта? :)
А если мы (вторая транзакция) наступаем на update conflict за одну наносекунду до коммита первой, то мы вполне можем подождать эту наносекунду (пока первая закоммитится), перепроверить условие в where, и совершить апдейт.
...
Рейтинг: 0 / 0
28.11.2013, 09:28:49
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38481175
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
NickDeeА если commit первой транзакции произошёл одну наносекунду назад, то уже всё ok? Мы (вторая транзакция) должны радоваться что не случилось конфликта? :)
представь себе, да. Потому что наносекунда назад, или год назад, совершенно без разницы.

NickDeeА если мы (вторая транзакция) наступаем на update conflict за одну наносекунду до коммита первой, то мы вполне можем подождать эту наносекунду (пока первая закоммитится), перепроверить условие в where, и совершить апдейт.
в момент апдейта произошел конфликт. Если эта транзакция read_committed, то в ней программист может перечитать данные и повторить update. Но за него никто повторять апдейт не будет. Если сервер будет повторять выполняемые программой операции, то это будет не сервер, а прямо искуственный интеллект.
А если это транзакция snapshot, то хоть обповторяйся, обновить запись будет невозможно.
...
Рейтинг: 0 / 0
28.11.2013, 10:07:32
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38481178
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Павел ИшенинА если с пониманием, что это повторный ajax request догнал первый и они оба прилетели на сервер одновременно?
ну так программа должна это понимать, и обрабатывать. А не висеть на lock wait а потом в ужасе сообщать, что произошел конфликт.
Я понимаю, что хотелось обойтись без написания кода, но увы, не получится.
...
Рейтинг: 0 / 0
28.11.2013, 10:09:15
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38481277
Павел Ишенин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Ишенин
Участник
dimitrПавел Ишенин,

если конфликты в принципе допустимы, но хочется уменьшить их число в таких ситуациях - рассмотри вариант с режимом изоляции read_committed no_record_version

Спасибо. Вкупе со следующим документом все стало понятнее.
...
Рейтинг: 0 / 0
28.11.2013, 10:59:40
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38481347
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Павел Ишенин,

в той статье не совсем верно сделаны выводы, этот режим не гарантирует сериализацию при более чем двух конкурентах. Просто вероятность конфликта меньше.
...
Рейтинг: 0 / 0
28.11.2013, 11:26:24
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38481348
Павел Ишенин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Ишенин
Участник
kdvну так программа должна это понимать, и обрабатывать. А не висеть на lock wait а потом в ужасе сообщать, что произошел конфликт.

Дима, рекомендации по написанию приложения, это offtopic. Но раз уж хочется, то:

1. lock wait используется только для отдельных запросов, которые наперед известно что могут прийти одновременно и с точки зрения приложения это нормально.
2. повисеть 10 секунд это тоже нормально, так как запрос асинхронный и в интерфейсе пользователь этого вообще не заметит никак.
3. ошибки этого запроса не сказываются на работоспособности приложения и не выводятся в интерфейсе пользователя.
...
Рейтинг: 0 / 0
28.11.2013, 11:26:34
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38481376
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Павел ИшенинДима, рекомендации по написанию приложения, это offtopic. Но раз уж хочется, то:
Павел, при wait конфликта не будет только если конкурирующая транзакция завершилась по rollback. Об этом, если уж хочется, можно прочитать в документации.
...
Рейтинг: 0 / 0
28.11.2013, 11:37:52
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38481406
Павел Ишенин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Ишенин
Участник
[quot kdv]Павел ИшенинПавел, при wait конфликта не будет только если конкурирующая транзакция завершилась по rollback. Об этом, если уж хочется, можно прочитать в документации.

Тем не менее, вариант Дмитрия Еманова на тестах в isql практически исключил появление указанной ошибки. Вторая конкурирующая транзакция стала ждать и завершаться без ошибок. Я полагаю, что все равно возможны ситуации с ошибкой, но их вероятность стала значительно ниже.
...
Рейтинг: 0 / 0
28.11.2013, 11:48:58
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38481445
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Павел ИшенинТем не менее, вариант Дмитрия Еманова на тестах в isql практически исключил появление указанной ошибки.
лишь бы софт не переписывать.
...
Рейтинг: 0 / 0
28.11.2013, 12:06:35
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38481493
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NickDee
Участник
kdvNickDeeА если мы (вторая транзакция) наступаем на update conflict за одну наносекунду до коммита первой, то мы вполне можем подождать эту наносекунду (пока первая закоммитится), перепроверить условие в where, и совершить апдейт.
в момент апдейта произошел конфликт. Если эта транзакция read_committed, то в ней программист может перечитать данные и повторить update.
Типа вот такого?:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
EXECUTE BLOCK as
begin
  UPDATE OR INSERT INTO USERS_LOG (USER_ID, LAST_ACTIVE, IP_ADDRESS) VALUES ('6F175349428A6A4A93E8B1D65B9BEA78', CURRENT_TIMESTAMP, '127.0.0.1') ;
  WHEN sqlcode -913 do  -- -904 do
  begin
--    if (gdscode = 335544451) then
--      EXCEPTION X cast(gdscode as varchar(20)); -- 335544336
    UPDATE OR INSERT INTO USERS_LOG (USER_ID, LAST_ACTIVE, IP_ADDRESS) VALUES ('6F175349428A6A4A93E8B1D65B9BEA78', CURRENT_TIMESTAMP, '127.0.0.1');
  end
END



Так работает. Только почему-то не получилось отловить по sqlcode -904 и по gdscode = 335544451, что соответствует ошибке показанной в IBExpert: "Update conflicts with concurrent update".

Я тут с обработкой ошибок отметил несколько неудобств и рудиментов.
Если бы я писал много кода на хранимках с обработкой ошибок, то очень быстро захотел бы обработки как в Delphi (для удобства и скорости). Работать с ошибками по номерам сильно удручает. И удручает что нет наследования. Наследования хотелось бы как для пользовательских эксепшэнов, так и для системных.
Почему бы нам в sql не хотеть себе таки же удобно, как в Delphi? :)
...
Рейтинг: 0 / 0
28.11.2013, 12:23:15
| Ответить | Цитировать | Написать  
deadlock при update записи
    #38482541
dennis-r
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dennis-r
Участник
NickDeeРаботать с ошибками по номерам сильно удручает.
И не надо:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
EXECUTE BLOCK as
begin
  UPDATE OR INSERT INTO USERS_LOG (USER_ID, LAST_ACTIVE, IP_ADDRESS) VALUES ('6F175349428A6A4A93E8B1D65B9BEA78', CURRENT_TIMESTAMP, '127.0.0.1') ;
  WHEN gdscode update_conflict do
  begin
      EXCEPTION X 'update_conflict'; -- 335544336
    UPDATE OR INSERT INTO USERS_LOG (USER_ID, LAST_ACTIVE, IP_ADDRESS) VALUES ('6F175349428A6A4A93E8B1D65B9BEA78', CURRENT_TIMESTAMP, '127.0.0.1');
  end
END
...
Рейтинг: 0 / 0
28.11.2013, 20:55:21
| Ответить | Цитировать | Написать  
49 сообщений из 49, показаны все 2 страниц
  все  
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / deadlock при update записи
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=40&tid=1564104]:
 0ms
get settings:
 8ms
get forum list:
 12ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 67ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 66ms
get tp. blocked users:
 2ms
others: 215ms
total:  392ms
созд. / загр.: 392ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]