Почему тупик Oracle без явной блокировки и фиксации уровня чтения?

Question

Я получаю эту ошибку Message: ORA-00060: deadlock detected while waiting for resource, хотя я не использую явную блокировку таблицы, и мой уровень изоляции установлен на READ COMMITTED.

Я использую несколько потоков поверх Spring TransactionTemplate с распространением по умолчанию. В моей бизнес-логике данные разделены так, что две транзакции никогда не будут иметь одинаковый набор данных. Для этого мне не нужно SERIALIZABLE

Почему Oracle может обнаружить тупик? В этом созвездии невозможны тупики, или я что-то упустил? Если я ничего не пропустил, тогда мой алгоритм разделения должен быть неправильным, верно? Или может быть какое-то другое объяснение?

Answer 1

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

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

LMK о том, что вы найдете, и о любых дополнительных вопросах….

К

Answer 2

Обнаружение взаимоблокировок не имеет ничего общего с уровнем сериализации.Когда строка вставлена ​​/ обновлена ​​/ удалена, оракул блокирует строку.Если у вас есть две транзакции, запущенные одновременно и пытающиеся изменить одну и ту же строку, вы можете столкнуться с тупиковой ситуацией.Акцент на "CAN".Обычно это происходит, если транзакции другого типа блокируются в другом порядке, что является признаком неправильного проектирования транзакций.

Как упоминалось ранее, при обнаружении тупика создается файл трассировки.Если вы посмотрите на файл трассировки, вы можете определить, какие два сеанса участвуют в тупике.Кроме того, он также показывает соответствующие операторы SQL.