простейший сервис на PHP, принимает запрос, читает, и пишет данные в таблицу.
Ошибка возникает когда приходит два запроса одновремено.

Вот что в логах по первому запросу:

авторerr: 23.08.2019 22:57:29 : (2)ibase_execute(): lock conflict on no wait transaction deadlock update conflicts with concurrent update concurrent transaction number is 16936694 in /srv/www/service.fitron/app/library/firebird/firebird.php at 207Array
(
[query] => update webdata set fvalue=? where idWebCome=29164 and fname=?
[param] => Array
(
[0] => Resource id #21
[1] => Новый клиент
[2] => TAG_NAME
)


вот что в логах по второму
авторerr: 23.08.2019 22:57:29 : (2)ibase_execute(): lock conflict on no wait transaction deadlock update conflicts with concurrent update concurrent transaction number is 16936694 in /srv/www/service.fitron/app/library/firebird/firebird.php at 207Array
(
[query] => update webdata set fvalue=? where idWebCome=29164 and fname=?
[param] => Array
(
[0] => Resource id #21
[1] => Хорошее
[2] => TAG_NAME
)


Вот сама функция выполняющая запрос на апдейт записи





Проблема, я так понимаю в этом "IBASE_WRITE | IBASE_NOWAIT | IBASE_COMMITTED | IBASE_REC_VERSION", а именно в параметрах транзакции.
IBASE_WRITE - пишущая транзакция
IBASE_NOWAIT - действия при конфликте, при данном режиме, СУБД не ждет завершения конфликтующей транзакции, а просто выдает ошибку. пробовал WAIT, но система просто ждет и так же вываливается в ошибку.
IBASE_COMMITTED - т.е. в данной транзакции все изменения, которые были подтверждены другими транзакциями, будут видны немедленно + IBASE_REC_VERSION игнорирует non-committed версии, читая последнюю committed-версию.

Подскажите, какие параметры пишущей транзакции поставить, чтобы два одновременных запроса на изменение одной и той же записи не конфликтовали друг с другом? но и видели все последние изменения commit других транзакций.

YuRock,

автор1. Не NOWAIT, а именно WAIT.

при таком варианте, просто ждет, и все равно вылетает ошибка

авторНе знаю, но очень сомневаюсь. Такое называется READ_COMMITED
IBASE_COMMITTED - это оно и есть

Dimitry SibiryakovsnakenestПодскажите, какие параметры пишущей транзакции поставить, чтобы два одновременных запроса
на изменение одной и той же записи не конфликтовали друг с другом?

Обломись. Базу надо переводить на Оракул или переделывать логику.


Oracle - хороший вариант, но лучше тогда на PostgreSQL

"или переделывать логику" ? как?
Пришли два запроса на http, одновременно, сервер запустил два потока, работают они одновременно, и оба запроса обновляют одну и туже запись.
Переписать Apache, можно, но долго. Налаживать взаимодействия между двумя процессами PHP - как?

Dimitry Sibiryakovsnakenest"или переделывать логику" ? как?

Убрать вот это самое "оба запроса обновляют одну и туже запись".
Ибо что-то протухло в этой консерватории.


т.е. выполнение одновременного Update одной записи - для firebird это невозможно ни при каких обстоятельствах ?

hvladsnakenest,

"логи" указывают на одну и ту же тр-цию конкурента. Т.е. либо у тебя 3 писателя, либо ты не те логи показываешь.

Далее, в запросе два маркера пар-ров, в логе видно что массив пар-ров из 3-х эл-тов.

И основной вопрос - ты уверен, что второй писатель может забить на то, что написал первый ?
Понятие lost update тебе знакомо ?

Обработка конфликта обновления обычно состоит из :
- откат тр-ции
- старт новой тр-ции
- перечитывание записи
- попытка апдейта
- проверка ошибки, коммит или всё сначала

Это оптимистичный подход, когда конфликты не часто случаются.
Некоторые СУБД в некоторых (не всех!) случаях применяют этот алгоритм самостоятельно.

Можно применить пессимистичный подход - заблокировать запись (select with lock в wait тр-ции) и потом её обновлять.

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

Три параметра, это особенности этого вызова:




первый параметр это ссылка на ресурс с транзакцией.


hvladИ основной вопрос - ты уверен, что второй писатель может забить на то, что написал первый ?
Да.
И поэтому я решил проблему изменив запрос на
"update webdata set fvalue=? where idWebCome=29164 and fname=? and fvalue is null"
тогда при срабатывании первого апдейта, остальные просто не могу обновить так как не срабатывает условие.

Но тут вопрос не в конкретном этом запросе. А именно, какие параметры пишущей транзакции позволят избежать блокировки при одновременном изменении одной и тойже записи.
Не ужели такое невозможно в Firebird?
Ведь он выдает deadlock, т.е. перед тем как произвести действия, проверяет и видит что прямо вот сейчас она уже меняется. Т.е. нельзя не выдавать deadlock, а просто поставить транзакцию в очередь и дождавшись окончания первой выполнить следующую?

По логике, так работать должен WAIT, но по факту это просто зависание и выдача того же deadlock только чуть позже, и при этом транзакции которая мешала, уже нет, она уже завершилась!