Цитата:
Сообщение от
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 не меняли?