Перерыл все интернеты, но никак не могу понять в чем может быть причина deadlock.

Имею след. запрос:

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

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 должна дождаться комита первой и выполнить запрос без ошибок.

Fr0sT-BrutalПочему у двух разных клиентов одинаковые ID (иначе не было бы concurrent update)? Если для каждого будет уникальный, то проблема исчезнет.

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

В принципе ничего ужасного в этих deadlock нет, но хотелось бы избавиться если это возможно.

Dimitry SibiryakovПавел Ишенинпо моему мнению, транзакция 2 должна дождаться комита первой и
выполнить запрос без ошибок.
Твоё мнение совпадает с мнением Ларри Эллисона, но отнюдь не Джима Старки. Поэтому иди-ка
с ним на Оракул.


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

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

Ivan_PisarevskyПавел Ишенинхотелось бы избавиться если это возможно.инсерт "наше фсё". Опционально можно зачистить во время периодических регламентных работ.

Записанная информация используется для отображения активности пользователя в web-приложении. Если использовать только insert, то усложнится запрос select, а как следствие и время извлечения информации из СУБД. А скорость времени выполнения запросов в web-приложениях критически важна.

Dimitry SibiryakovПавел ИшенинОтсюда и причина исходного вопроса о причине deadlock.

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


deadlock есть в сообщении об ошибке с сервера. В любом случае, спасибо. Из вашего сообщения я понял, что эту ошибку никак не исправить средствами СУБД, а следовательно нужно искать решения на стороне web-приложения.

Ivan_PisarevskyПавел ИшенинЕсли использовать только insertто не будет версий->мусора, который гарантированно появится при апдейтах.

Мусор в этом случае появится в самой таблице + дополнительный индекс.

Ivan_PisarevskyПавел ИшенинИногда этот запрос создает deadlock.А почему это проблема? Раз дэдлок, значит запись уже есть, сам же пользователь ее и апдейтит, чего ее апдейтить повторно? поймал, обработал, юзеру можно и не показывать.

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

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