|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Andrey_Так будет легче. Не будет. COUNT это точно такой же агрегат как и SUM. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 15:54 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovAndrey_Так будет легче. Не будет. COUNT это точно такой же агрегат как и SUM. Да, согласен, не учел, но тем не менее:Andrey_В случае баланса у меня нет конкурентных обновлений одного поля ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 15:57 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Andrey_В случае баланса у меня нет конкурентных обновлений одного поля Зато есть конкурентное обновление одной записи и... пони побежало на второй круг. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 16:01 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
В любом случае я понял ваши вопросы к архитектуре. Да, она не идеальна и вам удобно ее критиковать, но, может всетаки вернемся к обсуждению no_rec_version+wait? Должны транзакции с этими параметрами работать одинаково под разной нагрузкой или не должны? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 16:04 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Andrey_Должны транзакции с этими параметрами работать одинаково под разной нагрузкой или не должны? Не должны. Никому и ничего. Сериализация доступа делается транзакциями concurrency/consystency + explicit table lock. read committed и близко не валялся. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 16:06 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Andrey_, про no_rec_version, пишут люди http://www.ibase.ru/norecver/ Но - в вашем исходном посте лабуда. В том смысле, что - не имеет значения, потоки или не потоки, коннекты и прочая хрень. Транзакции всегда работают одинаково, хоть в тредах, хоть в отдельных процессах. - если сообщение deadlock выдается сразу, значит у транзакции режим nowait. Аминь. Andrey_С rec_version поведение при паралельном исполнении и при последовательном отличается нет, не отличается. у вас тест кривой, в одном случае есть wait, а в другом случае - nowait. Andrey_Должны транзакции с этими параметрами работать одинаково под разной нагрузкой или не должны? какая еще "нагрузка"? транзакции всегда работают одинаково, хоть 2, хоть 1000 штук. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 16:16 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
kdvAndrey_, про no_rec_version, пишут люди http://www.ibase.ru/norecver/ Но - в вашем исходном посте лабуда. В том смысле, что - не имеет значения, потоки или не потоки, коннекты и прочая хрень. Транзакции всегда работают одинаково, хоть в тредах, хоть в отдельных процессах. - если сообщение deadlock выдается сразу, значит у транзакции режим nowait. Аминь. Andrey_С rec_version поведение при паралельном исполнении и при последовательном отличается нет, не отличается. у вас тест кривой, в одном случае есть wait, а в другом случае - nowait. Andrey_Должны транзакции с этими параметрами работать одинаково под разной нагрузкой или не должны? какая еще "нагрузка"? транзакции всегда работают одинаково, хоть 2, хоть 1000 штук. не совсем. есть ньюансы на удалении/апдейте индексированных полей. нарывался лет пять назад. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 16:30 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
pastorесть ньюансы на удалении/апдейте индексированных полей. это ты путаешь с isc_dpb_no_garbage_collect ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 16:59 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
kdvпро no_rec_version, пишут люди http://www.ibase.ru/norecver/ Да, это я читал. А так же читал обсуждение этой статьи на sql.ru. И в обсуждении говорится, что статья не совсем соответствует действительности. И это я озвучил в этой ветке в посте 19458284 kdvНо - в вашем исходном посте лабуда. В том смысле, что - не имеет значения, потоки или не потоки, коннекты и прочая хрень. Транзакции всегда работают одинаково, хоть в тредах, хоть в отдельных процессах. Andrey_С rec_version поведение при паралельном исполнении и при последовательном отличается нет, не отличается. у вас тест кривой, в одном случае есть wait, а в другом случае - nowait. Лабуда, согласен. И я за нее уже извинился. В том же посте 19458284 kdv- если сообщение deadlock выдается сразу, значит у транзакции режим nowait. Аминь.Лог из всё того же поста, о котором я говорил: 19458284 Лог 12016-07-26T15:44:20.2350 (10048:000000000A70FBC0) START_TRANSACTION D:\DB\RDBTEST.FDB (ATT_4652, SYSDBA:NONE, UTF8, TCPv4:127.0.0.1) D:\projects\RDBTest\bin\Win32\Debug\RDBTest.exe:10832 (TRA_112343, READ_COMMITTED | NO_REC_VERSION | WAIT 7 | READ_WRITE) 2016-07-26T15:44:20.2350 (10048:000000000A70FBC0) EXECUTE_STATEMENT_START D:\DB\RDBTEST.FDB (ATT_4652, SYSDBA:NONE, UTF8, TCPv4:127.0.0.1) D:\projects\RDBTest\bin\Win32\Debug\RDBTest.exe:10832 (TRA_112343, READ_COMMITTED | NO_REC_VERSION | WAIT 7 | READ_WRITE) Statement 244: ------------------------------------------------------------------------------- update "Table1" set "Text" = ? , "Integer" = ? , "Float" = ? where "Id" = ? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ PLAN (Table1 INDEX (PKTable1)) param0 = varchar(8000), "qqq" param1 = integer, "112" param2 = bigint(*, -2), "215.00" param3 = integer, "18255" 2016-07-26T15:44:20.2360 (10048:00000000083D18C8) START_TRANSACTION D:\DB\RDBTEST.FDB (ATT_4651, SYSDBA:NONE, UTF8, TCPv4:127.0.0.1) D:\projects\RDBTest\bin\Win32\Debug\RDBTest.exe:10832 (TRA_112344, READ_COMMITTED | NO_REC_VERSION | WAIT 7 | READ_WRITE) 2016-07-26T15:44:20.2360 (10048:00000000083D18C8) EXECUTE_STATEMENT_START D:\DB\RDBTEST.FDB (ATT_4651, SYSDBA:NONE, UTF8, TCPv4:127.0.0.1) D:\projects\RDBTest\bin\Win32\Debug\RDBTest.exe:10832 (TRA_112344, READ_COMMITTED | NO_REC_VERSION | WAIT 7 | READ_WRITE) Statement 247: ------------------------------------------------------------------------------- update "Table1" set "Text" = ? , "Integer" = ? , "Float" = ? where "Id" = ? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ PLAN (Table1 INDEX (PKTable1)) param0 = varchar(8000), "qqq" param1 = integer, "215" param2 = bigint(*, -2), "159.00" param3 = integer, "18255" 2016-07-26T15:44:20.2380 (10048:000000000A70FBC0) COMMIT_TRANSACTION D:\DB\RDBTEST.FDB (ATT_4652, SYSDBA:NONE, UTF8, TCPv4:127.0.0.1) D:\projects\RDBTest\bin\Win32\Debug\RDBTest.exe:10832 (TRA_112343, READ_COMMITTED | NO_REC_VERSION | WAIT 7 | READ_WRITE) 0 ms, 2 write(s), 1 fetch(es), 1 mark(s) 2016-07-26T15:44:20.2380 (10048:00000000083D18C8) ERROR AT jrd8_execute D:\DB\RDBTEST.FDB (ATT_4651, SYSDBA:NONE, UTF8, TCPv4:127.0.0.1) D:\projects\RDBTest\bin\Win32\Debug\RDBTest.exe:10832 335544336 : deadlock 335544451 : update conflicts with concurrent update 335544878 : concurrent transaction number is 112343 ATT_4652 - обновляет запись в транзакции TRA_112343 ATT_4651 - стартует транзакцию TRA_112344 READ_COMMITTED | NO_REC_VERSION | WAIT 7 | READ_WRITE ATT_4651 - обновляет ту же запись в транзакции TRA_112344 и упирается в лок ATT_4652 - комитится ATT_4651 - вылетает с deadlock. update conflicts with concurrent update Лог 22016-07-26T16:14:29.4460 (10048:000000000A700590) START_TRANSACTION D:\DB\RDBTEST.FDB (ATT_4742, SYSDBA:NONE, UTF8, TCPv4:127.0.0.1) D:\projects\RDBTest\bin\Win32\Debug\RDBTest.exe:10728 (TRA_112515, READ_COMMITTED | NO_REC_VERSION | WAIT 500 | READ_WRITE) 2016-07-26T16:14:29.4470 (10048:000000000A700590) EXECUTE_STATEMENT_START D:\DB\RDBTEST.FDB (ATT_4742, SYSDBA:NONE, UTF8, TCPv4:127.0.0.1) D:\projects\RDBTest\bin\Win32\Debug\RDBTest.exe:10728 (TRA_112515, READ_COMMITTED | NO_REC_VERSION | WAIT 500 | READ_WRITE) Statement 44: ------------------------------------------------------------------------------- update "Table1" set "Text" = ? , "Integer" = ? , "Float" = ? where "Id" = ? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ PLAN (Table1 INDEX (PKTable1)) param0 = varchar(8000), "qqq" param1 = integer, "248" param2 = bigint(*, -2), "57.00" param3 = integer, "18255" 2016-07-26T16:14:30.5100 (10048:0000000000FB9F20) START_TRANSACTION D:\DB\RDBTEST.FDB (ATT_4744, SYSDBA:NONE, UTF8, TCPv4:127.0.0.1) D:\projects\RDBTest\bin\Win32\Debug\RDBTest.exe:9720 (TRA_112516, READ_COMMITTED | NO_REC_VERSION | WAIT 500 | READ_WRITE) 2016-07-26T16:14:30.5110 (10048:0000000000FB9F20) EXECUTE_STATEMENT_START D:\DB\RDBTEST.FDB (ATT_4744, SYSDBA:NONE, UTF8, TCPv4:127.0.0.1) D:\projects\RDBTest\bin\Win32\Debug\RDBTest.exe:9720 (TRA_112516, READ_COMMITTED | NO_REC_VERSION | WAIT 500 | READ_WRITE) Statement 59: ------------------------------------------------------------------------------- update "Table1" set "Text" = ? , "Integer" = ? , "Float" = ? where "Id" = ? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ PLAN (Table1 INDEX (PKTable1)) param0 = varchar(8000), "qqq" param1 = integer, "96" param2 = bigint(*, -2), "177.00" param3 = integer, "18255" 2016-07-26T16:14:32.1110 (10048:000000000A700590) COMMIT_TRANSACTION D:\DB\RDBTEST.FDB (ATT_4742, SYSDBA:NONE, UTF8, TCPv4:127.0.0.1) D:\projects\RDBTest\bin\Win32\Debug\RDBTest.exe:10728 (TRA_112515, READ_COMMITTED | NO_REC_VERSION | WAIT 500 | READ_WRITE) 1 ms, 2 write(s), 1 fetch(es), 1 mark(s) 2016-07-26T16:14:32.1110 (10048:0000000000FB9F20) EXECUTE_STATEMENT_FINISH D:\DB\RDBTEST.FDB (ATT_4744, SYSDBA:NONE, UTF8, TCPv4:127.0.0.1) D:\projects\RDBTest\bin\Win32\Debug\RDBTest.exe:9720 (TRA_112516, READ_COMMITTED | NO_REC_VERSION | WAIT 500 | READ_WRITE) Statement 59: ------------------------------------------------------------------------------- update "Table1" set "Text" = ? , "Integer" = ? , "Float" = ? where "Id" = ? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ PLAN (Table1 INDEX (PKTable1)) param0 = varchar(8000), "qqq" param1 = integer, "96" param2 = bigint(*, -2), "177.00" param3 = integer, "18255" 0 records fetched 1600 ms, 16 fetch(es), 2 mark(s) Table Natural Index Update Insert Delete Backout Purge Expunge *************************************************************************************************************** Table1 1 1 2016-07-26T16:14:33.5750 (10048:0000000000FB9F20) COMMIT_TRANSACTION D:\DB\RDBTEST.FDB (ATT_4744, SYSDBA:NONE, UTF8, TCPv4:127.0.0.1) D:\projects\RDBTest\bin\Win32\Debug\RDBTest.exe:9720 (TRA_112516, READ_COMMITTED | NO_REC_VERSION | WAIT 500 | READ_WRITE) 1 ms, 2 write(s), 1 fetch(es), 1 mark(s) ATT_4742 - обновляет запись в транзакции TRA_112515 ATT_4744 - стартует транзакцию TRA_112516 READ_COMMITTED | NO_REC_VERSION | WAIT 500 | READ_WRITE ATT_4744 - обновляет ту же запись в транзакции TRA_112516 и упирается в лок ATT_4742 - комитится транзакция TRA_112515 ATT_4744 - в транзакции TRA_112516 выполняется EXECUTE_STATEMENT_FINISH ATT_4744 - комитится транзакция TRA_112516 Я бы с удовольствием вам поверил, но логу я верю больше. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 17:01 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Andrey_логу я верю больше Результат параллельного выполнения двух последовательностей операций над одним объектом зависит от взаимного порядка выполнения отдельных операций и в общем случае без явной их сериализации непредсказуем. Это азы многопоточного программирования. Кого ты хотел удивить?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 17:18 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Andrey_, и что я должен понять из этих логов? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 17:22 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovAndrey_логу я верю больше Результат параллельного выполнения двух последовательностей операций над одним объектом зависит от взаимного порядка выполнения отдельных операций и в общем случае без явной их сериализации непредсказуем. Это азы многопоточного программирования. Кого ты хотел удивить?.. Мне кажется Firebird продвинулся дальше азов многопоточного программирования. И в случае атомарных операций (обновление записи в памяти например) на запись/страницу должна ставится эксклюзивная блокировка, которая предотвратит чтение другими потоками несогласованных данных. И да, я не совсем понимаю как связана ваша мысль с обсуждаемой ситуацией. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 17:32 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Andrey_И в случае атомарных операций (обновление записи в памяти например) на запись/страницу должна ставится эксклюзивная блокировка, которая предотвратит чтение другими потоками несогласованных данных. 1. Firebird не блокировочник. 2. update записи - не атомарная операция. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 17:34 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
kdvи что я должен понять из этих логов?То что я писал раньше в этой ветке 19458284 : Andrey_В случае низкой паралельности запросов (кнопочками из двух приложений апдейты/комиты кормлю серверу) транзакция2 спокойно апдейтит запись, которую изменила транзакция1, после комита транзакции1. В случае высокой паралельности (паралельные потоки по ивенту отправляющие апдейты на одну запись) транзакция2 вылетает с "update conflicts with concurrent update" при комите транзакции1. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 17:36 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov1. Firebird не блокировочник. 2. update записи - не атомарная операция. То что Firebird не блокировочник, не значит, что у него нет изменяемых ресурсов с конкурентным доступом. В любом случае при добавлении новой версии записи нужно куда-то записать ссылку на эту версию. С точки зрения процессора - да, update записи конечно не атомарная операция. А с точки зрения транзакции - атомарная. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 17:42 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Andrey_В любом случае при добавлении новой версии записи нужно куда-то записать ссылку на эту версию. Да. И на время этой операции страница данных блокируется эксклюзивно. Но этот лок отпускается срезу после этого. Andrey_С точки зрения процессора - да, update записи конечно не атомарная операция. А с точки зрения транзакции - атомарная. Да. Поэтому она либо происходит вся целиком, либо не происходит вообще. И что? Твой лог не показывает частичного update. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 17:46 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovAndrey_В любом случае при добавлении новой версии записи нужно куда-то записать ссылку на эту версию. Да. И на время этой операции страница данных блокируется эксклюзивно. Но этот лок отпускается срезу после этого. Andrey_С точки зрения процессора - да, update записи конечно не атомарная операция. А с точки зрения транзакции - атомарная. Да. Поэтому она либо происходит вся целиком, либо не происходит вообще. И что? Твой лог не показывает частичного update. Я не понимаю что мы сейчас обсуждаем. Мы меряемся знаниями в многопоточном программировании? Это явный оффтопик. Лог показывает то что в нем написано. Как я интерпритирую его содержимое, я описал рядом с ним. И в моем понимании это ошибка. Где я не прав? Хотя вы уже говорили, что поведение у транзакций может отличаться под разной нагрузкой, по этому скорее вопрос к остальным участникам ветки. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 18:15 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Andrey_Я не понимаю что мы сейчас обсуждаем. Мы меряемся знаниями в многопоточном программировании? Мы ничего не обсуждаем. Я объясняю тебе где именно ты ошибаешься. Но если ты не хочешь слушать - твой право. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 18:22 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Andrey_Мне ехать. Ехать так как работает no_rec_version при низкой нагрузке.Она работает не так, как тебе кажется. То, что "при низкой нагрузке" она работает "как хочется" - просто совпадение. Безконфликтная сериализация апдейтов делается или SELECT WITH LOCK или явным резервированием таблиц (слишком грубый метод, нужно уметь пользоваться). ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 18:56 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Andrey_Подсистема 1 выполняет поиск подходящего заказа для этого водителя и записывает ID заказа в запись водителя. Подсистема 2 выполняет перерасчет баланса водителя (и всякой другой фин.информации) и записывает ее в запись водителя. Подсистема 3 выполняет актуализацию геоданных водителя (полученных с того же смартфона) и записывает ее в запись водителя И в это же время асинхронно работают другие шедулеры выполняющие другие действия над водителями...Возможно тут поможет разбиение "запись водителя" на несколько независимо редактируемых таблиц + создание VIEW ""запись водителя"" (чтобы было как раньше) + триггеры на обновление VIEW ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 18:59 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Hello, Hvlad! You wrote on 27 июля 2016 г. 19:00:57: Hvlad> Возможно тут поможет разбиение "запись водителя" на несколько независимо редактируемых таблицне внемлет. предлагали. ТС упорот упорно стоит на своём. хоть это так больно, такой кайфолом... (с) Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 19:02 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovМы ничего не обсуждаем. Я объясняю тебе где именно ты ошибаешься. Но если ты не хочешь слушать - твой право. Окей. Вернемся к вашей мысли:авторРезультат параллельного выполнения двух последовательностей операций над одним объектом зависит от взаимного порядка выполнения отдельных операций и в общем случае без явной их сериализации непредсказуемТо что FB ставит эксклюзивные блокировки на страницу при ее изменении и является явной сериализацией. То есть апдейты одной записи (того что хранится в памяти на странице) должны обрабатываться последовательно. А если последовательно, то и результат должен быть предсказуем. Да, еще блокировки индексов есть, да и почти любой другой разделяемый объект нужно блокировать при изменении. Но, если запросы одинаковые, то и сценарий блокировок будет одинаковый (допустим от индекса, по которому выполняется поиск, к записи) и между ними не возникнет дедлоков. По этому я не понимаю откуда там взялся дедлок. ...или понимаю. Если используется оптимистичный подход (а я почти уверен что так и есть), и эксклюзивная блокировка страницы происходит только непосредственно перед записью новой версии на страницу. Возможна такая ситуация, что обе транзакции вычитали одну и ту же запись (с одинаковой историей версий), обе создали у себя новую версию (дельты там, сжатие, все дела), первая успела записать новую версию на страницу, а вторая при попытке записи обнаружила, что версия записи, которая должна ссылаться на новую уже ссылается на что-то (ну или как-то иначе определила, что та версия которую она создала - бракованая). Это конечно не дедлок, но вылететь с лок конфликт в такой ситуации можно... А можно и корректно обработать создав новую версию на основании той истории версий, которая есть сейчас. Как сильно я ошибаюсь теперь? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 19:17 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Andrey_Мы меряемся знаниями в многопоточном программировании? Это явный оффтопик. какой-то абсурд. Firebird-у все равно, где стартуют транзакции. в многопоточном приложении, или в N одновременно работающих приложений - абсолютно по барабану. Andrey_По этому я не понимаю откуда там взялся дедлок. у ФБ, исторически, как и у ИБ - deadlock это как попытка апдейта уже существующей версии записи (не committed), так и взаимоблокировка, настоящий deadlock. В режиме no_rec_version deadlock еще и выдается при попытке чтения не committed записи. Даже только что вставленной, которую, якобы, никто видеть не в состоянии. Andrey_ну или как-то иначе определила, что та версия которую она создала - бракованая нет никаких "бракованных" версий. конфликт обновления опознается только в момент обновления, или чтения (no_rec_ver), других конфликтов не бывает. И конфликт обновления опознается по наличию версии, которая создана не-committed транзакцией. Andrey_ можно и корректно обработать создав новую версию на основании той истории версий см. выше. никакая "история версий" не нужна. Читаем пакет версий, проверяем состояние транзакций - если не committed, значит при update выдаем deadlock (или при чтении в no_rec_ver выдаем deadlock). Соответственно, не-коммиттед версия может существовать только одна. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 19:25 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
hvladТо, что "при низкой нагрузке" она работает "как хочется" - просто совпадение. Безконфликтная сериализация апдейтов делается или SELECT WITH LOCK или явным резервированием таблиц (слишком грубый метод, нужно уметь пользоваться).Вот теперь дошло. Очень жаль, что совпадение. Ну и ладно, когда жареный петух клюнет, будем или разделять таблицы или SELECT WITH LOCK, а скорее и то и другое. Пока просто иногда появляются необъяснимые дедлоки. Спасибо. kdvЧитаем пакет версий, проверяем состояние транзакций - если не committed, значит при update выдаем deadlock (или при чтении в no_rec_ver выдаем deadlock). Соответственно, не-коммиттед версия может существовать только одна.Да, но мы то находимся в wait-транзакции. Хорошо было бы, чтобы она все же ждала свой очереди на апдейт. Но тут конечно куча нюансов с вопросом "А чья же сейчас очередь". Ну да ладно, нет так нет. Зачастую сложно угадать каким образом пользователи будут использовать твою систему, а такую гибкую как FB, так и подавно. Вот и нашелся такой пользователь как я, пытающийся сделать сериализацию с помощью не подходящих инструментов. В свое оправдание должен заметить, что при "низкой нагрузке" FB вел себя как я и предполагал. Всем спасибо. P.S. hvlad я постараюсь воспроизвести тот краш базы, что был у меня. Но возможно это моя вина, я мог запутаться и подключиться к базе тройки с сервера 2.5. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 19:43 |
|
Забавное поведение rec_version в wait-транзакциях
|
|||
---|---|---|---|
#18+
Andrey_hvlad я постараюсь воспроизвести тот краш базы, что был у меня.Спасибо, это важно. Andrey_Но возможно это моя вина, я мог запутаться и подключиться к базе тройки с сервера 2.5.Такие вещи не должны ломать БД. Ну и - 2.5 не откроет БД от 3.0 и наоборот. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2016, 23:18 |
|
|
start [/forum/topic.php?fid=40&msg=39281418&tid=1561953]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
50ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
70ms |
get tp. blocked users: |
2ms |
others: | 22ms |
total: | 192ms |
0 / 0 |