InventDim::findOrCreate

[Владимир Максимов]

Цитата:

Сообщение от ice

все у вас правильно, только момент между 1 и 3 очень маленький и вероятность вклинивания 2 очень мала. а вот вероятность попадания в описанную мной ситуацию очень большая

Ничего подобного. Я просто описал тот процесс, который Вы и пытаетесь симулировать. Т.е. попытку "одновременного" создания записи двумя пользователями. Поскольку для процессора такого понятия в принципе не существует, то, с точки зрения процессора, эта самая "одновременность" будет разбита именно на описанные мною шаги.

Если подходить с точки зрения стороннего наблюдателя, то будет казаться, что выполняются следующие процессы

1. Оба пользователя "одновременно" открыли транзакцию
2. Оба пользователя "одновременно" выполнили поиск аналитики.
3. Оба пользователя "одновременно" ничего не нашли
4. Оба пользователя "одновременно" попытались создать новую запись. Один создал, другой "завис" до завершении транзакции первого пользователя
5. Первый пользователь завершил транзакцию, второй попытался создать запись - получил ошибку

Но поскольку "одновременность" - это иллюзия, создаваемая компьютером, то логично разбить процесс на понятные последовательные этапы. Что я и сделал в самом начале.

Однако во всей этой схеме "тонкий" момент - это момент поиска. Поиск осуществляется командой

select inventDim where ...

И вот тут-то и возникает вопрос настроек "по умолчанию". Причем настроек именно AOS.

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

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

В этом случае сценарий будет похож на то, что описал S.Kuskov, но с одной существенной поправкой:

1. Оба пользователя "одновременно" открыли транзакцию
2. Оба пользователя "одновременно" начали поиск
3. Один из них закончил поиск первым и успел создать запись
4. Тогда другой "подвиснет" в процессе поиска и его поиск останется не завершенным до окончания транзакции первого пользователя
5. Первый пользователь завершил транзакцию
6. Второй пользователь продолжил поиск и нашел запись созданную первым
7. Второй пользователь также успешно завершил транзакцию

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

А отсюда возвращаемся к вопросу

Цитата:

Сообщение от _scorp_

Может у Вас включены какие-то дополнительные хинты для SQL?

PS: Кстати, "случайно" режим кеширования таблицы InventDim не меняли?

[S.Kuskov]

Цитата:

Сообщение от Владимир Максимов

дополнительное соединение здесь никак не поможет. Поскольку в этом дополнительном соединении запрос также пойдет с хинатми грязного чтения

Дополнительное соединение призвано изменить поведение не второго клиента (для него действительно принципиально ничего не измениться), а первого! Суть в том что если первый клиент не будет откладывать вставку нового значения в InventDim до завершения своей транзакции (используя дополнительное соединение это возможно, верно?), то к моменту когда второй клиент будет искать заданную комбинацию - он её найдёт(!). При этом основная транзакция первого клиента может быть ещё не завершена. Ещё раз, дополнительное соединение используется для выноса действий по вставке значения из основной транзакции (длинной) в отдельную (короткую).

Цель - получить следующую последовательность действий:
1. Первый пользователь открыл основную транзакцию
2. ...Первый пользователь открыл фоновую транзакцию в отдельном соединении
3. ...Первый пользователь в отдельном соединении выполнил findOrCreate
4. ...Первый пользователь подтвердил фоновую транзакцию (новая комбинация складских аналитик окончательно запостилась в таблицу)
5. Второй пользователь открыл свою транзакцию
6. Второй пользователь выполнил InventDim::find() - нашёл запись!
7. Второй пользователь подтвердил свою транзакцию
8. Первый пользователь подтвердил свою основную транзакцию

[ice]

Цитата:

Сообщение от S.Kuskov

Дополнительное соединение призвано изменить поведение не второго клиента (для него действительно принципиально ничего не измениться), а первого! Суть в том что если первый клиент не будет откладывать вставку нового значения в InventDim до завершения своей транзакции (используя дополнительное соединение это возможно, верно?), то к моменту когда второй клиент будет искать заданную комбинацию - он её найдёт(!). При этом основная транзакция первого клиента может быть ещё не завершена. Ещё раз, дополнительное соединение используется для выноса действий по вставке значения из основной транзакции (длинной) в отдельную (короткую).

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

[Владимир Максимов]

Цитата:

Сообщение от ice

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

Ааа, так речь идет о "длинных" транзакциях. Тогда был не прав. Не о том говорил. В этом случае действительно отдельное соединение поможет.

Правда пока не сталкивался с тем, чтобы тормоза вызывал именно процесс вставки одинаковых складских аналитик. Вероятно, это сильно зависит от бизнес-процессов.