ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / deadlock при update записи
24 сообщений из 49, страница 2 из 2
  2  все
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
| Ответить | Цитировать | Написать  
24 сообщений из 49, страница 2 из 2
  2  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / deadlock при update записи
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=38480481&tid=1564104]:
 0ms
get settings:
 6ms
get forum list:
 10ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 177ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 36ms
get tp. blocked users:
 1ms
others: 187ms
total:  432ms
созд. / загр.: 432ms
x
x
Закрыть


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