Забавное поведение rec_version в wait-транзакциях / Firebird, InterBase

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Забавное поведение rec_version в wait-транзакциях

74 сообщений из 74, показаны все 3 страниц

все

Забавное поведение rec_version в wait-транзакциях

#39279890

Andrey_

Гость

Здравствуйте. Заметил интересное поведение сервера отдаленно напоминающее ошибку:

FB 2.5.5 Super x64, fbclient x32 из этого же дистрибутива, Win64, Delphi XE5, FIB
2 коннекта, у каждого по транзакции:
isc_tpb_read_committed
isc_tpb_rec_version
isc_tpb_wait
isc_tpb_lock_timeout

Выполняется апдейт одной и той же записи (update t set f='NewValue' where Id=:pId), никакой обвязки на таблице, даже PK нет.

tr1.Start
tr2.Start
update1.exec
update2.exec

Если последовательно - всё ожидаемо, update2 через 5 секунд вываливается с "Lock time-out on wait transaction. Deadlock. Update conflicts with concurrent update."

А вот если коннекты разделены по потокам (коннект+транзакция+апдейт), и запустить потоки паралельно (очень паралельно, потоки привязанные к разным ядрам слушают один эвент и стартуют апдейт), жертва вылетает сразу (без ожидания 5 сек) вот так: "Deadlock. Update conflicts with concurrent update."

Лечится установкой no_rec_version. В результате последовательно и паралельно работает одинаково (с ожиданием).
Мне это кажется странным. wait должен или работать полностью в транзакциях с rec_version или не работать в таких транзакциях совсем.

Пожалуйста, киньте тыц где это описано. Или объясните на пальцах где я не прав.

P.S. Да, в реальном приложении такой ситуации (двойной паралельный апдейт одной записи) не возникнет, это тестовое приложение, оно эмулирует работу комплекса приложений в котором даже невозможное возможно.
P.P.S. Да, я знаю, что супер 2.5 не очень SMP. Тестироваться будет и FB 3.0 и какой-нибудь MSSQL, просто начал с FB 2.5 как с самой знакомой платформы.

...

Рейтинг:

0 / 0

25.07.2016, 19:26

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39279892

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

Andrey_wait должен или работать полностью в транзакциях с rec_version или не работать в таких
транзакциях совсем.

Он и работает. Просто первый поток завершает транзакцию мгновенно и второй таки дожидается
этого момента.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

25.07.2016, 19:29

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39279982

Док

Участник

Откуда: Казань

Сообщения: 7 363

Рейтинг: 0 / 0

Andrey_оно эмулирует работу комплекса приложений в котором даже невозможное возможно
дабл_таблоид детектед :)

...

Рейтинг:

0 / 0

25.07.2016, 23:13

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39279995

Andrey_

Гость

Dimitry SibiryakovОн и работает.Мне кажется - нет. С rec_version поведение при паралельном исполнении и при последовательном отличается. А с no_rec_version поведение одинаковое.
Если бы первывй поток "завершал транзакцию мгновенно", то поведение ни чем не отличалось бы от последовательного.

Докдабл_таблоид детектед :) Не я такой, ТЗ такое :) Хотя это конечно не оправдание.

...

Рейтинг:

0 / 0

26.07.2016, 01:06

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39280178

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

Andrey_Мне кажется - нет.
Когда кажется - надо включать аудит и изучать последовательность операций на сервере по нему.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

26.07.2016, 11:41

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39280214

Andrey_

Гость

Dimitry SibiryakovКогда кажется - надо включать аудит и изучать последовательность операций на сервере по нему.А вот и спасибо, про вариант отладки с этой стороны я позабыл. На недельке займусь и отпишу тут. Пока меня устроит no_rec_version для update-транзакций.

...

Рейтинг:

0 / 0

26.07.2016, 12:07

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39280529

Andrey_

Гость

Решил таки доковырять проблему.

Итого rec_version ведет себя таки адекватно - дожидаясь завершения блокирующей транзакции и после этого вываливаясь с исключением. Как при низком уровне паралельности, так и при высоком. Снимаю шляпу, был не прав.

А вот с no_rec_version возникли вопросы. И, к сожалению, именно no_rec_version мне нужен будет в реальной системе. Или select for update, но это печально.
В случае низкой паралельности запросов (кнопочками из двух приложений апдейты/комиты кормлю серверу) транзакция2 спокойно апдейтит запись, которую изменила транзакция1, после комита транзакции1.
В случае высокой паралельности (паралельные потоки по ивенту отправляющие апдейты на одну запись) транзакция2 вылетает с "update conflicts with concurrent update" при комите транзакции1. И в логах сервера это подтверждается. Логи во вложении.

P.S. Коннект по 127.0.0.1, по этому про плохую сеть даже не пофантазировать.
P.P.S. тыц и тыц изучены. Первый тыц подтверждает мою теорию, но у меня такое даже на 2 транзакциях воспроизводится стабильно, а у товарища на 3.
P.P.P.S. Я конечно это проверю и на FB 3.0, но если там поведение такое-же... мне остается только оборочивать апдейты в try...except в банальном тестовом приложении. А когда адепты MSSQL посмотрят в мой код и спросят "А зачем это у тебя так? Оно что, может свалиться?", я не буду знать что ответить.

Такие дела. Жду Ваших комментариев :)

...

Рейтинг:

0 / 0

26.07.2016, 17:16

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39280535

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

Andrey_И, к сожалению, именно no_rec_version мне нужен будет в реальной системе.

http://www.gunsmoker.ru/2008/10/x-y-z.html detected
Тебе надо не обрабатывать конфликты, а предотвращать их. А это требует определённой
архитектуры как БД так и приложения.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

26.07.2016, 17:22

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39280566

Andrey_

Гость

Dimitry SibiryakovТебе надо не обрабатывать конфликты, а предотвращать их. А это требует определённой
архитектуры как БД так и приложения.Да... но нет.
Во первых потому что такая разница в поведении - это ошибка.
Во вторых потому что системы бывают не только новые, но и существующие. Причем существующие уже давно и, как следствие, имеющие очень высокую цену на изменение архитектуры. Пробежаться по коду и заменить X на Y легко, но сколько итераций полнофункционального тестирования для данного изменения будет, это болезненный вопрос.

...

Рейтинг:

0 / 0

26.07.2016, 17:46

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39280651

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

Andrey_Или select for update, но это печально.И что тут печального ?

...

Рейтинг:

0 / 0

26.07.2016, 20:18

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39280670

Andrey_

Гость

hvladAndrey_Или select for update, но это печально.И что тут печального ?Два запроса вместо одного. Ну, или хранимку апдейтящую на каждый чих, или холостой апдейт. И всё это вместо нативного no_rec_version.

...

Рейтинг:

0 / 0

26.07.2016, 21:06

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39280673

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

Чисто для ознакомления: http://www.sql.ru/forum/964534/hranimye-agregaty-bez-konfliktov-i-blokirovok-recept

...

Рейтинг:

0 / 0

26.07.2016, 21:19

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39280713

Andrey_

Гость

Dimitry SibiryakovЧисто для ознакомления: http://www.sql.ru/forum/964534/hranimye-agregaty-bez-konfliktov-i-blokirovok-recept Спасибо, познавательно, возможно после детального изучения куда-то и применю. Но не моя ситуация, у меня нет агрегатов и они не нужны. По крайне мере я пока не вижу куда их применить.

...

Рейтинг:

0 / 0

27.07.2016, 00:02

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39280726

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

Andrey_hvladпропущено...
И что тут печального ?Два запроса вместо одного.EXEC BLOCK, если к процедурам аллергия

PS в "проблему" не вникал

...

Рейтинг:

0 / 0

27.07.2016, 01:41

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39280990

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

Andrey_не моя ситуация, у меня нет агрегатов
Тогда как ты умудряешься получать update conflict?
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

27.07.2016, 11:53

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281101

Andrey_

Гость

hvladAndrey_Два запроса вместо одного.EXEC BLOCK, если к процедурам аллергияВ целом те же яйца, что и процедура. В итоге при апдейте мне нужно просить сервер выполнить два запроса вместо одного. Всегда. Конечно с where current of это полтора запроса, а не два, но всеравно больше чем один.

hvladPS в "проблему" не вникалИ это тоже печалит.

Dimitry SibiryakovТогда как ты умудряешься получать update conflict?

Псэудокоде Делфисайл

Код: pascal

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.

Thread0
  FWakeupEvent := CreateEvent(nil, true, false, '')
  Thread1.Create(false)
  Thread2.Create(false)
  подождать пока Thread1 и Thread2 дойдут до WaitForSingleObject
  SetEvent(FWakeupEvent)
Thread1
  CPUAffinity(2);
  create Connect, Transaction, Query
  connect
  WaitForSingleObject(FWakeupEvent)
  StartTransaction
  Execute(update)
  Commit
Thread2
  CPUAffinity(4);
  create Connect, Transaction, Query
  connect
  WaitForSingleObject(FWakeupEvent)
  StartTransaction
  Execute(update)
  Commit

Это то что я называю "высокий паралельность". Когда запросы действительно идут одновременно. После нескольких итераций (а иногда и на первой итерации) апдейт, который пришел на сервер чуть позже сразу вылетает с update conflict. Без ожидания. На всякий случай:

Параметры транзакций

Код: sql

1.
2.
3.
4.

isc_tpb_read_committed
isc_tpb_no_rec_version
isc_tpb_wait
isc_tpb_lock_timeout=7

Логи сервера я уже выкладывал выше, и для последовательных запросов и для паралельных.

На релизе FB 3.0 (Super/SuperClassic) проверил - поведение не отличается. А после N-ого количества итераций теста при select из тестовой таблицы получил "database file appears corrupt (D:\DB\RDBTEST_3.0.FDB).
wrong page type.
page 177 is of wrong type (expected data, found unknown (89))."
Сценария порчи базы не нашел.

...

Рейтинг:

0 / 0

27.07.2016, 12:50

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281112

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

Andrey_Это то что я называю "высокий паралельность".

Я это называю "крайний дебилизм".

Ты мне по-простому, на пальцах объясни: вот лежит в БД "Иванов Иван Иванович" и внезапно
один пользователь БД решил переименовать его в Петрова, а второй, так же внезапно, в ту же
миллисекунду - в Сидорова. Вопрос: с какого перепою и кто им разрешил это делать?
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

27.07.2016, 12:57

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281131

Andrey_

Гость

Dimitry SibiryakovЯ это называю "крайний дебилизм".

Ты мне по-простому, на пальцах объясни: вот лежит в БД "Иванов Иван Иванович" и внезапно
один пользователь БД решил переименовать его в Петрова, а второй, так же внезапно, в ту же
миллисекунду - в Сидорова. Вопрос: с какого перепою и кто им разрешил это делать?
А... ну да, дибилизм. Когда в таблице одно поле, конечно дибилизм. Но иногда бывает, что в таблице больше одного поля, и один "пользователь" меняет одно поле, а другой другое поле. Конечно это всё решается, если разделить поля по разным таблицам связанным 1:1. Но это тот самый вопрос смены архитектуры существующей системы, который уже обсуждали.

...

Рейтинг:

0 / 0

27.07.2016, 13:09

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281138

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

Andrey_один "пользователь" меняет одно поле, а другой другое поле.

И опять возникает вопрос: с какого перепою и на каком основании?

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

PPS: Для смены архитектуры существующей системы существует такая удобная вещь как view.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

27.07.2016, 13:13

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281139

Симонов Денис

Участник

Откуда: Рязань

Сообщения: 11 624

Рейтинг: 0 / 0

Dimitry Sibiryakov,
+1

Andrey_ ,

ты можешь привести реальный пример когда это требуется, а не абстрактные размышления?

...

Рейтинг:

0 / 0

27.07.2016, 13:13

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281232

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

Andrey_В целом те же яйца, что и процедура. В итоге при апдейте мне нужно просить сервер выполнить два запроса вместо одного. Всегда. Конечно с where current of это полтора запроса, а не два, но всеравно больше чем один.Тебе шашечки, или ехать ? В конкурентном мире подходы не совпадают с последовательным, такова селяви. Собственно подходов два:
1. оптимистичный: прочитали, проверили - если подходит, пробуем взять себе, не получилось - повторяем
2. пессимистичный: захватили, потом проверяем

SELECT WITH LOCK - как раз второй подход. Что выбрать - решать тебе.

И вообще - с чего ты взял, что no_rec_version хоть как-то влияет на update ?
Оно обещает (и делает) подождать при чтении (селекте), если тр-ция записи активна.
Но никто не обещал делать этого при записи (апдейте).

Andrey_На релизе FB 3.0 (Super/SuperClassic) проверил - поведение не отличается. А после N-ого количества итераций теста при select из тестовой таблицы получил "database file appears corrupt (D:\DB\RDBTEST_3.0.FDB).
wrong page type.
page 177 is of wrong type (expected data, found unknown (89))."А вот это я очень хотел бы воспроизвести.

...

Рейтинг:

0 / 0

27.07.2016, 14:25

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281290

Andrey_

Гость

Dimitry SibiryakovИ опять возникает вопрос: с какого перепою и на каком основании?Симонов Денисты можешь привести реальный пример когда это требуется, а не абстрактные размышления?

Реальный примерДано:
Диспетчерская такси. У этой диспетчерской есть водители и заказы. У водителей есть смартфоны. С помощью приложений на смартфонах водители коммуницируют с диспетчерской.
Сценарий:
Водитель выполнил заказ и в приложении на смартфоне поставил галку "Свободен"
Приложение со смартфона записало эту информацию в базу FB (через третье звено или на прямую - не важно)
Каким-то волшебным образом (ведь в FB нельзя привязывать к ивентам идентификаторы) все подсистемы диспетчерской узнали что водитель выполнил заказ. И начинается карусель:
Подсистема 1 выполняет поиск подходящего заказа для этого водителя и записывает ID заказа в запись водителя.
Подсистема 2 выполняет перерасчет баланса водителя (и всякой другой фин.информации) и записывает ее в запись водителя.
Подсистема 3 выполняет актуализацию геоданных водителя (полученных с того же смартфона) и записывает ее в запись водителя
И в это же время асинхронно работают другие шедулеры выполняющие другие действия над водителями...

А еще, перед тем как поставить галку "Свободен" водитель позвонил в диспетчерскую и попросил поставить его в какой-то сектор. И диспетчер ручками меняет запись водителя через свое приложение.

Все эти действия происходят асинхронно. И любые 2 и более могут совпасть по времени. И да, это всё нужно паралелить, потому что это не более 20% от всей функциональности, а в пиковые моменты число заказов измеряется десятками в секунду

Но! Но. В превую это может понадобится потому что работа под высокой нагрузкой и под низкой нагрузкой должна отличатся только временем отклика, но никак не сценарием поведения СУБД. Это делает СУБД предсказуемой.

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

PPS: Для смены архитектуры существующей системы существует такая удобная вещь как view.Да всё что угодно можно разделить, даже одну сущность по нескольким таблицам размазать, и даже может быстрее некоторые операции будут работать (записи то узкими станут). Правда другие операции станут гораздо медленнее. Потому что нужно будет или писать тригеры на вьюху (если с клиентов мы апдейтим вьюху) и в них проверять что же изменилось и делать соответствующие апдейты таблиц, или писать тригеры на таблицы (если мы с клиентов апдейтим таблицы а не вьюху) и в них собирать запись из кусков размазаных по разным таблицам чтобы проверить какое-то условие, поля которого "не относятся к данной сущности". Вопрос не в этом.

hvladТебе шашечки, или ехать ?Мне ехать. Ехать так как работает no_rec_version при низкой нагрузке.

hvladИ вообще - с чего ты взял, что no_rec_version хоть как-то влияет на update ?
Оно обещает (и делает) подождать при чтении (селекте), если тр-ция записи активна.
Но никто не обещал делать этого при записи (апдейте).Ну... не смотря на то что этого никто не обещал, по моим наблюдениям (которые подтверждаются логами сервера) и при апдейте влияет. rec_version - всегда дожидается своего таймаута/завершения конкурента. no_rec_version обычно дожидается завершения конкурента, но иногда вылетает сразу.

hvladА вот это я очень хотел бы воспроизвести.На недельке повращаю базу по разному. Но ничего не обещаю.

...

Рейтинг:

0 / 0

27.07.2016, 15:10

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281300

Симонов Денис

Участник

Откуда: Рязань

Сообщения: 11 624

Рейтинг: 0 / 0

Andrey_Подсистема 1 выполняет поиск подходящего заказа для этого водителя и записывает ID заказа в запись водителя.
Подсистема 2 выполняет перерасчет баланса водителя (и всякой другой фин.информации) и записывает ее в запись водителя.
Подсистема 3 выполняет актуализацию геоданных водителя (полученных с того же смартфона) и записывает ее в запись водителя
И в это же время асинхронно работают другие шедулеры выполняющие другие действия над водителями...

с какого бодуна все эти подсистемы работают с одной таблицей? Это же разные сущности.
Всегда считал что это ID водителя должно в заказ писаться, а не наоборот.

Andrey_выполняет перерасчет баланса водителя (и всякой другой фин.информации) и записывает ее в запись водителя.

а говорил агрегатов нет...

...

Рейтинг:

0 / 0

27.07.2016, 15:19

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281301

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

Andrey_Реальный пример
И тут-то из всех щелей полезли балансы, текущий заказ и прочие хранимые агрегаты, которых
"нет".
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

27.07.2016, 15:20

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281316

Andrey_

Гость

Господа, как вы на слово "баланс" то накинулись :)
Повторюсь, у меня нет агрегатов и смысла в них не вижу. Считайте, что это не баланс, а количество выполненных заказов (банальный X=X+1). Так будет легче.

Но, не спорю, для уменьшения конкуренции можно это всё складывать в отдельную табличку, а потом когда-нибудь ночью агрегировать. Но зачем? В случае баланса у меня нет конкурентных обновлений одного поля.

И да, в водителе таки должен храниться заказ, т.к. способов назначить заказ водителю существует минимум 6 (всё что сходу вспомнил) и большинство из них могут конкурировать между собой. Поле это нужно чтобы конкуренты не перезаписали друг друга. Просто update Driver set OrderId=:pOrderId where DriverId=:pDriverId and OrderId is null

...

Рейтинг:

0 / 0

27.07.2016, 15:36

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281337

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

Andrey_Так будет легче.
Не будет. COUNT это точно такой же агрегат как и SUM.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

27.07.2016, 15:54

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281344

Andrey_

Гость

Dimitry SibiryakovAndrey_Так будет легче.
Не будет. COUNT это точно такой же агрегат как и SUM.
Да, согласен, не учел, но тем не менее:Andrey_В случае баланса у меня нет конкурентных обновлений одного поля

...

Рейтинг:

0 / 0

27.07.2016, 15:57

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281351

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

Andrey_В случае баланса у меня нет конкурентных обновлений одного поля

Зато есть конкурентное обновление одной записи и... пони побежало на второй круг.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

27.07.2016, 16:01

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281356

Andrey_

Гость

В любом случае я понял ваши вопросы к архитектуре. Да, она не идеальна и вам удобно ее критиковать, но, может всетаки вернемся к обсуждению no_rec_version+wait? Должны транзакции с этими параметрами работать одинаково под разной нагрузкой или не должны?

...

Рейтинг:

0 / 0

27.07.2016, 16:04

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281359

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

Andrey_Должны транзакции с этими параметрами работать одинаково под разной нагрузкой или не должны?

Не должны. Никому и ничего. Сериализация доступа делается транзакциями
concurrency/consystency + explicit table lock. read committed и близко не валялся.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

27.07.2016, 16:06

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281369

kdv

Участник

Откуда: iBase.ru

Сообщения: 30 139

Рейтинг: 0 / 0

Andrey_,

про no_rec_version, пишут люди
http://www.ibase.ru/norecver/

Но - в вашем исходном посте лабуда. В том смысле, что
- не имеет значения, потоки или не потоки, коннекты и прочая хрень. Транзакции всегда работают одинаково, хоть в тредах, хоть в отдельных процессах.
- если сообщение deadlock выдается сразу, значит у транзакции режим nowait. Аминь.
Andrey_С rec_version поведение при паралельном исполнении и при последовательном отличается
нет, не отличается. у вас тест кривой, в одном случае есть wait, а в другом случае - nowait.
Andrey_Должны транзакции с этими параметрами работать одинаково под разной нагрузкой или не должны?
какая еще "нагрузка"? транзакции всегда работают одинаково, хоть 2, хоть 1000 штук.

...

Рейтинг:

0 / 0

27.07.2016, 16:16

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281385

pastor

Участник

Откуда: Калуга

Сообщения: 1 274

Рейтинг: 0 / 0

kdvAndrey_,

про no_rec_version, пишут люди
http://www.ibase.ru/norecver/

Но - в вашем исходном посте лабуда. В том смысле, что
- не имеет значения, потоки или не потоки, коннекты и прочая хрень. Транзакции всегда работают одинаково, хоть в тредах, хоть в отдельных процессах.
- если сообщение deadlock выдается сразу, значит у транзакции режим nowait. Аминь.
Andrey_С rec_version поведение при паралельном исполнении и при последовательном отличается
нет, не отличается. у вас тест кривой, в одном случае есть wait, а в другом случае - nowait.
Andrey_Должны транзакции с этими параметрами работать одинаково под разной нагрузкой или не должны?
какая еще "нагрузка"? транзакции всегда работают одинаково, хоть 2, хоть 1000 штук.

не совсем. есть ньюансы на удалении/апдейте индексированных полей.

нарывался лет пять назад.

...

Рейтинг:

0 / 0

27.07.2016, 16:30

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281414

kdv

Участник

Откуда: iBase.ru

Сообщения: 30 139

Рейтинг: 0 / 0

pastorесть ньюансы на удалении/апдейте индексированных полей.
это ты путаешь с isc_dpb_no_garbage_collect

...

Рейтинг:

0 / 0

27.07.2016, 16:59

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281418

Andrey_

Гость

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 READ_COMMITTED | NO_REC_VERSION | WAIT 7 | READ_WRITE
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 READ_COMMITTED | NO_REC_VERSION | WAIT 500 | READ_WRITE
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

Я бы с удовольствием вам поверил, но логу я верю больше.

...

Рейтинг:

0 / 0

27.07.2016, 17:01

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281426

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

Andrey_логу я верю больше
Результат параллельного выполнения двух последовательностей операций над одним объектом
зависит от взаимного порядка выполнения отдельных операций и в общем случае без явной их
сериализации непредсказуем. Это азы многопоточного программирования. Кого ты хотел удивить?..
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

27.07.2016, 17:18

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281428

kdv

Участник

Откуда: iBase.ru

Сообщения: 30 139

Рейтинг: 0 / 0

Andrey_,

и что я должен понять из этих логов?

...

Рейтинг:

0 / 0

27.07.2016, 17:22

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281433

Andrey_

Гость

Dimitry SibiryakovAndrey_логу я верю больше
Результат параллельного выполнения двух последовательностей операций над одним объектом
зависит от взаимного порядка выполнения отдельных операций и в общем случае без явной их
сериализации непредсказуем. Это азы многопоточного программирования. Кого ты хотел удивить?..
Мне кажется Firebird продвинулся дальше азов многопоточного программирования. И в случае атомарных операций (обновление записи в памяти например) на запись/страницу должна ставится эксклюзивная блокировка, которая предотвратит чтение другими потоками несогласованных данных.
И да, я не совсем понимаю как связана ваша мысль с обсуждаемой ситуацией.

...

Рейтинг:

0 / 0

27.07.2016, 17:32

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281436

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

Andrey_И в случае атомарных операций (обновление записи в памяти например) на запись/страницу
должна ставится эксклюзивная блокировка, которая предотвратит чтение другими потоками
несогласованных данных.
1. Firebird не блокировочник.
2. update записи - не атомарная операция.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

27.07.2016, 17:34

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281438

Andrey_

Гость

kdvи что я должен понять из этих логов?То что я писал раньше в этой ветке 19458284 :
Andrey_В случае низкой паралельности запросов (кнопочками из двух приложений апдейты/комиты кормлю серверу) транзакция2 спокойно апдейтит запись, которую изменила транзакция1, после комита транзакции1.
В случае высокой паралельности (паралельные потоки по ивенту отправляющие апдейты на одну запись) транзакция2 вылетает с "update conflicts with concurrent update" при комите транзакции1.

...

Рейтинг:

0 / 0

27.07.2016, 17:36

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281442

Andrey_

Гость

Dimitry Sibiryakov1. Firebird не блокировочник.
2. update записи - не атомарная операция.
То что Firebird не блокировочник, не значит, что у него нет изменяемых ресурсов с конкурентным доступом. В любом случае при добавлении новой версии записи нужно куда-то записать ссылку на эту версию.
С точки зрения процессора - да, update записи конечно не атомарная операция. А с точки зрения транзакции - атомарная.

...

Рейтинг:

0 / 0

27.07.2016, 17:42

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281444

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

Andrey_В любом случае при добавлении новой версии записи нужно куда-то записать ссылку на эту версию.

Да. И на время этой операции страница данных блокируется эксклюзивно. Но этот лок
отпускается срезу после этого.

Andrey_С точки зрения процессора - да, update записи конечно не атомарная операция. А с точки
зрения транзакции - атомарная.

Да. Поэтому она либо происходит вся целиком, либо не происходит вообще. И что? Твой лог не
показывает частичного update.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

27.07.2016, 17:46

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281465

Andrey_

Гость

Dimitry SibiryakovAndrey_В любом случае при добавлении новой версии записи нужно куда-то записать ссылку на эту версию.

Да. И на время этой операции страница данных блокируется эксклюзивно. Но этот лок
отпускается срезу после этого.
Andrey_С точки зрения процессора - да, update записи конечно не атомарная операция. А с точки
зрения транзакции - атомарная.

Да. Поэтому она либо происходит вся целиком, либо не происходит вообще. И что? Твой лог не
показывает частичного update.
Я не понимаю что мы сейчас обсуждаем. Мы меряемся знаниями в многопоточном программировании? Это явный оффтопик.

Лог показывает то что в нем написано. Как я интерпритирую его содержимое, я описал рядом с ним. И в моем понимании это ошибка. Где я не прав? Хотя вы уже говорили, что поведение у транзакций может отличаться под разной нагрузкой, по этому скорее вопрос к остальным участникам ветки.

...

Рейтинг:

0 / 0

27.07.2016, 18:15

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281472

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

Andrey_Я не понимаю что мы сейчас обсуждаем. Мы меряемся знаниями в многопоточном программировании?

Мы ничего не обсуждаем. Я объясняю тебе где именно ты ошибаешься. Но если ты не хочешь
слушать - твой право.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

27.07.2016, 18:22

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281493

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

Andrey_Мне ехать. Ехать так как работает no_rec_version при низкой нагрузке.Она работает не так, как тебе кажется.
То, что "при низкой нагрузке" она работает "как хочется" - просто совпадение.
Безконфликтная сериализация апдейтов делается или SELECT WITH LOCK или явным резервированием таблиц (слишком грубый метод, нужно уметь пользоваться).

...

Рейтинг:

0 / 0

27.07.2016, 18:56

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281494

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

Andrey_Подсистема 1 выполняет поиск подходящего заказа для этого водителя и записывает ID заказа в запись водителя.
Подсистема 2 выполняет перерасчет баланса водителя (и всякой другой фин.информации) и записывает ее в запись водителя.
Подсистема 3 выполняет актуализацию геоданных водителя (полученных с того же смартфона) и записывает ее в запись водителя
И в это же время асинхронно работают другие шедулеры выполняющие другие действия над водителями...Возможно тут поможет разбиение "запись водителя" на несколько независимо редактируемых таблиц + создание VIEW ""запись водителя"" (чтобы было как раньше) + триггеры на обновление VIEW

...

Рейтинг:

0 / 0

27.07.2016, 18:59

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281496

Мимопроходящий

Участник

Откуда: бурятский тундрюк, эсквайр

Сообщения: 33 443

Рейтинг: 0 / 0

Hello, Hvlad!
You wrote on 27 июля 2016 г. 19:00:57:

Hvlad> Возможно тут поможет разбиение "запись водителя" на несколько независимо редактируемых таблицне внемлет.
предлагали.
ТС упорот упорно стоит на своём.

хоть это так больно, такой кайфолом... (с)

Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

27.07.2016, 19:02

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281499

Andrey_

Гость

Dimitry SibiryakovМы ничего не обсуждаем. Я объясняю тебе где именно ты ошибаешься. Но если ты не хочешь
слушать - твой право.
Окей. Вернемся к вашей мысли:авторРезультат параллельного выполнения двух последовательностей операций над одним объектом
зависит от взаимного порядка выполнения отдельных операций и в общем случае без явной их
сериализации непредсказуемТо что FB ставит эксклюзивные блокировки на страницу при ее изменении и является явной сериализацией. То есть апдейты одной записи (того что хранится в памяти на странице) должны обрабатываться последовательно. А если последовательно, то и результат должен быть предсказуем. Да, еще блокировки индексов есть, да и почти любой другой разделяемый объект нужно блокировать при изменении. Но, если запросы одинаковые, то и сценарий блокировок будет одинаковый (допустим от индекса, по которому выполняется поиск, к записи) и между ними не возникнет дедлоков.

По этому я не понимаю откуда там взялся дедлок.

...или понимаю. Если используется оптимистичный подход (а я почти уверен что так и есть), и эксклюзивная блокировка страницы происходит только непосредственно перед записью новой версии на страницу. Возможна такая ситуация, что обе транзакции вычитали одну и ту же запись (с одинаковой историей версий), обе создали у себя новую версию (дельты там, сжатие, все дела), первая успела записать новую версию на страницу, а вторая при попытке записи обнаружила, что версия записи, которая должна ссылаться на новую уже ссылается на что-то (ну или как-то иначе определила, что та версия которую она создала - бракованая). Это конечно не дедлок, но вылететь с лок конфликт в такой ситуации можно... А можно и корректно обработать создав новую версию на основании той истории версий, которая есть сейчас.

Как сильно я ошибаюсь теперь?

...

Рейтинг:

0 / 0

27.07.2016, 19:17

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281502

kdv

Участник

Откуда: iBase.ru

Сообщения: 30 139

Рейтинг: 0 / 0

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).
Соответственно, не-коммиттед версия может существовать только одна.

...

Рейтинг:

0 / 0

27.07.2016, 19:25

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281511

Andrey_

Гость

hvladТо, что "при низкой нагрузке" она работает "как хочется" - просто совпадение.
Безконфликтная сериализация апдейтов делается или SELECT WITH LOCK или явным резервированием таблиц (слишком грубый метод, нужно уметь пользоваться).Вот теперь дошло. Очень жаль, что совпадение.
Ну и ладно, когда жареный петух клюнет, будем или разделять таблицы или SELECT WITH LOCK, а скорее и то и другое. Пока просто иногда появляются необъяснимые дедлоки.
Спасибо.

kdvЧитаем пакет версий, проверяем состояние транзакций - если не committed, значит при update выдаем deadlock (или при чтении в no_rec_ver выдаем deadlock).
Соответственно, не-коммиттед версия может существовать только одна.Да, но мы то находимся в wait-транзакции. Хорошо было бы, чтобы она все же ждала свой очереди на апдейт. Но тут конечно куча нюансов с вопросом "А чья же сейчас очередь". Ну да ладно, нет так нет.

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

Всем спасибо.

P.S. hvlad я постараюсь воспроизвести тот краш базы, что был у меня. Но возможно это моя вина, я мог запутаться и подключиться к базе тройки с сервера 2.5.

...

Рейтинг:

0 / 0

27.07.2016, 19:43

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281568

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

Andrey_hvlad я постараюсь воспроизвести тот краш базы, что был у меня.Спасибо, это важно.

Andrey_Но возможно это моя вина, я мог запутаться и подключиться к базе тройки с сервера 2.5.Такие вещи не должны ломать БД. Ну и - 2.5 не откроет БД от 3.0 и наоборот.

...

Рейтинг:

0 / 0

27.07.2016, 23:18

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281569

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

Andrey_Если используется оптимистичный подход (а я почти уверен что так и есть), и эксклюзивная блокировка страницы происходит только непосредственно перед записью новой версии на страницу. Firebird, в отличие от того же MSSQL не удерживает страничные блокировки до окончания тр-ции (ибо страничные блокировки не являются механизмом обеспечения изоляции тр-ции).
Ему достаточно взять краткую блокировку только на время непосредственного изменения страницы (такие блокировки ещё называют латчами).

Andrey_Возможна такая ситуация, что обе транзакции вычитали одну и ту же запись (с одинаковой историей версий), обе создали у себя новую версию (дельты там, сжатие, все дела), первая успела записать новую версию на страницу, а вторая при попытке записи обнаружила, что версия записи, которая должна ссылаться на новую уже ссылается на что-то (ну или как-то иначе определила, что та версия которую она создала - бракованая). Это конечно не дедлок, но вылететь с лок конфликт в такой ситуации можно... Это уже ближе к тому, что там происходит :)

Andrey_А можно и корректно обработать создав новую версию на основании той истории версий, которая есть сейчас.Для этого нужно:
- откатить всю работу, которую сделали между первоначальным чтением и созданием новой версии
- повторить всю эту работу, основываясь на обновлённой OLD версии
- молиться, чтобы кто-то снова не втиснулся до нас со своим апдейтом

Т.е. мало того, что тут происходит потенциальная беготня по кругу, но и никто не знает сколько там
работы сделали before триггеры - может они пол-бд перечитали и заменили.

Посему решение о повторе работы лежит на программисте, а не навязывается автоматом.

...

Рейтинг:

0 / 0

27.07.2016, 23:26

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281728

Arioch

Участник

Сообщения: 11 207

Рейтинг: 0 / 0

Andrey_подключиться к базе тройки с сервера 2.5.

если ты имеешь в виду поключиться к серверу тройке через fbclient.dll от 2.5 - то это наплевать.
тут могут возникнуть вопросы уровня сетевого обмена, но с самим файлом БД работает только сервер, и ему почти все равно, кто ему поставляет команды.

если ты имеешь в виджу файл БД с ODS 12 открыть сервером FB 2.5 или файл ODS 11.x открыть сервером FB 3 - то это невозможно.

...

Рейтинг:

0 / 0

28.07.2016, 11:21

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281740

Симонов Денис

Участник

Откуда: Рязань

Сообщения: 11 624

Рейтинг: 0 / 0

Andrey_Но возможно это моя вина, я мог запутаться и подключиться к базе тройки с сервера 2.5.

Это не возможно. А вот перепутать локальный протокол с embedded можно.

...

Рейтинг:

0 / 0

28.07.2016, 11:30

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281818

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

...

Рейтинг:

0 / 0

28.07.2016, 12:43

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281823

Andrey_

Гость

Симонов ДенисAndrey_Но возможно это моя вина, я мог запутаться и подключиться к базе тройки с сервера 2.5.Это не возможно. А вот перепутать локальный протокол с embedded можно.Сам перечитал, что написал. В общем ничего криминального вроде не делал. Вряд ли это описание принесет пользу, но чтобы не забыть как что было, оставлю его тут.
Что я делал:
Ставил FB 3 из дистрибутива Firebird-3.0.0.32483_2_x64, при инсталяции он правильно определил, что у меня установлен 2.5 и отказался выполнять э...начальные настройки.
Сервер запускал с ключем -a (это dev-машина и я предполагал что потребуется частое переключение между 2.5 и 3.0, а настраивать их одновременную работу не хотелось т.к. они нужны поочереди)
На клиенте использовал fbclient.dll из WOW64
Строка подключения всегда была вида 127.0.0.1:D:\и т.д. (с новыми протоколами пока не разбирался, попробовал что так работает и ладно)
Базу бекапил клиентом и сервером 2.5, ресторил клиентом и сервером 3.0
В firebird.conf менял только ServerMode, игрался с разными вариантами (восновном Super и SuperClassic, непомню запускал ли я тест на Classic или нет.)

Клиентское приложение стартовало 43 потока, каждый выполнял коннект к базе (10 инсерт-потоков, 10 апдейтящих по одной рандомной записи, 3 апдейтящих одну и ту же рандомную запись, 20 читающих эту же рандомную запись). 2 раза в секунду во все потоки приходил ивент по которому они все стартовали транзакцию, выполняли кто-что должен и коммитились. Это не моя идея такого теста, я бы проеверял, как всегда, скорость отклика на N-условно паралельных запросов.

При завершении работы приложения я старался корректно выполнять disconnect, но часто некоторые потоки зависали из-за эксепшенов (те самые лок конфликты) и я приложение срубал через Ctrl+F2 из Delphi или в диспетчере задач когда standalone.
То есть, при срубании могло оставаться 1-4 коннекта с открытыми транзакциями.

Тестовых запусков приложения было порядка 15. Восновном они были короткие т.к. происходило зависание потоков. Но были и тесты крутившиеся несколько минут.

Других коннектов к серверу (IBExpert например) небыло.

Краш был обнаружен на утро следующего дня. Не уверен что это важно, вроде в FB нет шедулеров работающих с диском по таймеру. Ну кроме управляемого MaxUnflushedWriteTime, но этот параметр я не трогал.

Ошибка выдается при запросе select * from "Table1"

статистика базыDatabase "D:\DB\RDBTEST_3.0.FDB"
Database header page information:
Flags 0
Generation 29095
System Change Number 0
Page size 16384
ODS version 12.0
Oldest transaction 28854
Oldest active 28901
Oldest snapshot 28901
Next transaction 28902
Sequence number 0
Next attachment ID 612
Implementation HW=AMD/Intel/x64 little-endian OS=Windows CC=MSVC
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Jul 26, 2016 18:33:10
Attributes force write

Variable header data:
Sweep interval: 20000
*END*

Database file sequence:
File D:\DB\RDBTEST_3.0.FDB is the only file

Analyzing database pages ...
Expected data on page 177
Table1 (128)
Primary pointer page: 163, Index root page: 164
Pointer pages: 1, data page slots: 1632
Data pages: 1632, average fill: 78%
Primary pages: 1295, secondary pages: 337, swept pages: 621
Empty pages: 5, full pages: 1344
Fill distribution:
0 - 19% = 176
20 - 39% = 69
40 - 59% = 20
60 - 79% = 90
80 - 99% = 1276

Index PKTable1 (0)
Root page: 1006, depth: 2, leaf buckets: 13, nodes: 35444
Average node length: 5.30, total dup: 0, max dup: 0
Average key length: 3.00, compression ratio: 1.27
Average prefix length: 2.82, average data length: 1.00
Clustering factor: 2786, ratio: 0.08
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 1
60 - 79% = 0
80 - 99% = 11

Table2 (129)
Primary pointer page: 167, Index root page: 168
Pointer pages: 1, data page slots: 1608
Data pages: 1608, average fill: 80%
Primary pages: 1312, secondary pages: 296, swept pages: 632
Empty pages: 3, full pages: 1354
Fill distribution:
0 - 19% = 143
20 - 39% = 72
40 - 59% = 20
60 - 79% = 89
80 - 99% = 1284

Index FKTable2Table1 (1)
Root page: 1015, depth: 2, leaf buckets: 19, nodes: 36000
Average node length: 5.16, total dup: 7996, max dup: 27
Average key length: 2.85, compression ratio: 1.34
Average prefix length: 3.01, average data length: 0.81
Clustering factor: 20372, ratio: 0.57
Fill distribution:
0 - 19% = 0
20 - 39% = 5
40 - 59% = 8
60 - 79% = 0
80 - 99% = 6

Index PKTable2 (0)
Root page: 597, depth: 2, leaf buckets: 13, nodes: 35445
Average node length: 5.30, total dup: 0, max dup: 0
Average key length: 3.00, compression ratio: 1.27
Average prefix length: 2.82, average data length: 1.00
Clustering factor: 2927, ratio: 0.08
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 1
60 - 79% = 0
80 - 99% = 11

И да, господа, я знаю что прежде чем говорить "я тестировал" нужно разобраться в инструменте который тестируешь. Давайте сейчас это не будем обсуждать, цель - найти последовательность действий для краша базы, а не наставить меня на путь истинный по поводу использования дефолтного конфига.
И еще, не трогайте пожалуйста меня за двойные кавычки. Я сам их терпеть не могу, но опять же, корпоративный CodeStyle.

...

Рейтинг:

0 / 0

28.07.2016, 12:45

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39281835

Arioch

Участник

Сообщения: 11 207

Рейтинг: 0 / 0

hvlad,

почти не может

исключение - когда аппликуха падает и вместе с ней падает сaм embedded с непредсказуемыми последствиями

или ещё хуже, аппликуха не падает но тихо "срёт в память" и попадает иногда в кэши встройки

за что я его и не люблю

...

Рейтинг:

0 / 0

28.07.2016, 12:54

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39282116

Andrey_

Гость

hvlad
Удалось относительно стабильно воспроизвести краш базы.

Всё окружение, как я описывал раньше, те самые 43 коннекта. После нескольких итераций теста (когда на сервер одновременно уходит 43 запроса) в логе FB появляется ошибка:

USER-PC Thu Jul 28 17:11:20 2016
Database: D:\DB\RDBTEST_3.0_CORRUPTION.FDB
internal Firebird consistency check (cannot find tip page (165), file: tra.cpp line: 2307)

После этого иногда сервер падает, иногда работает, но при выключении иногда зависает, а иногда вылетает (иконка в трее не ищезает :)) Вобщем, в результате первой ошибки структуры в памяти оказываются повреждены.
Если с таким не полностью упавшим сервером продолжить работать, иногда это приводит к wrong page type.

Крашится как Super так как SuperClassic.

Сейчас жду разрешения от начальства, чтобы выслать не поломанный бекап+исходники тестов (они вообще для другого делались).

В любом случае, даже если разрешения не будет, дома заново напишу. Кстати, куда высылать?

...

Рейтинг:

0 / 0

28.07.2016, 17:44

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39282181

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

Andrey_,

спасибо.

Ошибка, правда, совсем другая, но это может быть связано.

Высылай на hvlad at users sourceforge net, если есть возможность куда-то выложить - тем лучше.
Если стабильно воспроизводится, то можно exe, без исходников.

...

Рейтинг:

0 / 0

28.07.2016, 19:17

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39282327

Andrey_

Гость

hvlad,

Отправил с исходниками. Руководство дало свое высочайшее соизволение.

...

Рейтинг:

0 / 0

29.07.2016, 00:48

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39282429

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

Andrey_,

Спасибо. Можешь выслать exe ? Не у всех есть Delphi, тем более нужной версии :)
И, я надеюсь, путь к БД, логин и пароль не вшиты в exe, можно будет задать свои ?

PS провайдер глючит с отправкой почты, поэтому пишу тут

...

Рейтинг:

0 / 0

29.07.2016, 09:50

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39283139

Andrey_

Гость

hvlad,

Только добрался до компьютера. Выслал бинарник с файлом параметров.

Очень жаль, что не у всех установлено делфи нужной версии :) Хотя, это делает меня, как специалиста, более ценным. И когда ко мне приходят бинарники, я боюсь их запускать, по этому подумал, что будет лучше без него.

...

Рейтинг:

0 / 0

29.07.2016, 20:23

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39286732

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

Andrey_,

проблему воспроизвёл, баг в fb3 подтверждаю.
Он весьма специфичный и, похоже, достаточно редкий.

Исправление будет через пару дней, надеюсь.
Ещё раз спасибо

...

Рейтинг:

0 / 0

04.08.2016, 23:30

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39290617

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

http://tracker.firebirdsql.org/browse/CORE-5327

...

Рейтинг:

0 / 0

11.08.2016, 20:41

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39290844

Andrey_

Гость

hvlad http://tracker.firebirdsql.org/browse/CORE-5327 Спасибо, тоже проверю. Позже. А на 2.5 бекпорт не планируется?
P.S. Тестовый пример с исходниками можно распостранять т.к. если исходники вышли за пределы компании, их нельзя считать privat.

...

Рейтинг:

0 / 0

12.08.2016, 10:59

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39290878

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

Andrey_А на 2.5 бекпорт не планируется?Эта ошибка появилась в fb3 (с 64-битными номерами тр-ций), так что я сильно сомневаюсь, что 2.5 затронут ;)

Если наши тестеры не смогут сделать воспроизводимый пример своими силами, приаттачу exe, спасибо.

...

Рейтинг:

0 / 0

12.08.2016, 11:22

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39315854

Andrey_

Гость

Andrey_hvlad http://tracker.firebirdsql.org/browse/CORE-5327 Спасибо, тоже проверю. Позже...Позже настало. И совершенно случайно я нашел 100% путь воспроизведения. Тот бекап, что я высылал ресторится с ошибками. Точнее при ресторе (с ключами -r -rep) он не говорит, что есть ошибки, но валидация (с ключами -v -n) по свежеотрестореной базе выдает вот такое в firebird.log:

USER-PC Mon Sep 26 17:30:39 2016
Database: D:\DB\RDBTEST_3.0.FDB
Validation started

USER-PC Mon Sep 26 17:30:39 2016
Database: D:\DB\RDBTEST_3.0.FDB
Error: Page 177 wrong type (expected data encountered unknown (89))

USER-PC Mon Sep 26 17:30:39 2016
Database: D:\DB\RDBTEST_3.0.FDB
Error: Data page 177 {sequence 0} is confused in table Table1 (128)

USER-PC Mon Sep 26 17:30:39 2016
Database: D:\DB\RDBTEST_3.0.FDB
Validation finished: 2 errors, 0 warnings, 0 fixed

И в дальнейшем при работе с такой базой сервер ведет себя непредсказуемо (спамит ошибки Page XXX wrong type в firebird.log + кушает памяти больше, чем дозволено). Проверил на релизном билде 3.0 (Firebird-3.0.0.32483_2_x64) и на текущем снапшоте (Firebird-3.0.1.32609-0_x64) - поведение идентично.

Могу повторно выслать бекап, если потерялся за давностью лет.

...

Рейтинг:

0 / 0

26.09.2016, 17:48

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39315894

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

Andrey_,

проверил на текущем снапшоте - валидация ошибок не даёт.
Ты уверен, что ресторил\проверял на новом билде ?

...

Рейтинг:

0 / 0

26.09.2016, 19:17

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39315895

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

Andrey_,

проверил на 3.0.0.32483-2_x64 - проблему не вижу

...

Рейтинг:

0 / 0

26.09.2016, 19:21

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39315913

kdv

Участник

Откуда: iBase.ru

Сообщения: 30 139

Рейтинг: 0 / 0

Andrey_Точнее при ресторе (с ключами -r -rep)
и чем же эти ключи отличаются от -c в плане создания шаблона БД и заливки туда метаданных и данных?

...

Рейтинг:

0 / 0

26.09.2016, 20:31

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39316169

Andrey_

Гость

hvladAndrey_, на 3.0.0.32483-2_x64 - проблему не вижуПрошу прощения, сам запутался и ввел всех в заблуждение - ресторил одну базу, а валидировал другую. Если рестор+валидацию делать с правильной базой - валидация никаких ошибок не выдает. Я рак, мне стыдно. В будущем буду более тщательно проверять условия экспериментов.

kdvAndrey_Точнее при ресторе (с ключами -r -rep)
и чем же эти ключи отличаются от -c в плане создания шаблона БД и заливки туда метаданных и данных?Возможно ничем. Кроме того что в описании ключа rep явно написано слово -replace. А мне и нужно replace. А в описании ключа -c этого слова не написано.

offtopПожалуйста, поймите:
1. Не все кто обращается сюда с вопросами, последние 10 лет занимаются исключительно фаербердом. Для многих СУБД это 3-4-10 по приоритету задача.
2. Из-за высокой скорости современных компьютеров в последнее время стало очень популярно "программирование брутфорсом". Это когда написал-скомпилировал-ошибка-передал-скомпилировал-запустил-ошибка-переделал-скомпилировал-запустил-работает-ЗАБЫЛ про задачу и переключился на следующую.

И, к сожалению, я подхожу в обе категории. По этому я глубоко не вникал в смысл, механику работы, причины появления, побочные эффекты от сочетаний и другие особенности каждого ключа. Я сделал просто - перед рестором я прочитал что в консоль выдает gbak, подобрал подходящие по описанию опции, попробовал, заработало, написал батник и ЗАБЫЛ про задачу.

О причинах почему сейчас сложилось именно так можно написать целую книгу, но я лучше пойду поработаю - кушать хочется больше, чем словоблудить.

...

Рейтинг:

0 / 0

27.09.2016, 12:18

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39316187

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

Andrey_Прошу прощения, сам запутался и ввел всех в заблуждение - ресторил одну базу, а валидировал другуюУ всех бывает :)

...

Рейтинг:

0 / 0

27.09.2016, 12:43

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39317390

kdv

Участник

Откуда: iBase.ru

Сообщения: 30 139

Рейтинг: 0 / 0

Andrey_Возможно ничем. Кроме того что в описании ключа rep явно написано слово -replace. А мне и нужно replace. А в описании ключа -c этого слова не написано.
не надо привыкать к хреновым опциям. Как показывает практика, -replace не нужен вообще никогда и ни за чем.
http://www.ibase.ru/gbak/#restore

Что здесь отсутствует? Правильно, знакомый многим параметр -r. Параметр -r на самом деле не -r[estore], а -r[eplace], т.е. не "восстановить", а "заменить" имеющуюся базу данных. Т.е. если в предыдущем примере команды заменить -c на -r, то существующая база данных e.fdb будет молча удалена. Этого допускать нельзя, потому что по разным причинам восстановление из резервной копии может не состояться, и тогда вы останетесь без оригинальной базы данных и с невосстановимой резервной копией.

...

Рейтинг:

0 / 0

29.09.2016, 02:13

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39317517

miwaonline

Участник

Сообщения: 2 274

Рейтинг: 0 / 0

kdvКак показывает практика, -replace не нужен вообще никогда и ни за чем.
Мне нужен. Всегда и везде.

...

Рейтинг:

0 / 0

29.09.2016, 09:43

| Ответить | Цитировать | Написать

Забавное поведение rec_version в wait-транзакциях

#39317670

Мимопроходящий

Участник

Откуда: бурятский тундрюк, эсквайр

Сообщения: 33 443

Рейтинг: 0 / 0

Hello, Miwaonline!
You wrote on 29 сентября 2016 г. 11:32:48:

Miwaonline> Мне нужен. Всегда и везде.+1
у нас рестор выполняется на отдельном резервном сервере.
7 папочек по дням недели.
в каждой соответственно восстановленная база на этот день.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

29.09.2016, 11:35

| Ответить | Цитировать | Написать

74 сообщений из 74, показаны все 3 страниц

все

Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Забавное поведение rec_version в wait-транзакциях

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?all=1&fid=40&tid=1561953]:	0ms
get settings:	10ms
get forum list:	14ms
check forum access:	4ms
check topic access:	4ms
track hit:	52ms
get topic data:	12ms
get forum data:	3ms
get page messages:	86ms
get tp. blocked users:	2ms
others:	270ms

total:	457ms