При анализе тупика, вызванного двумя одновременными операторами SELECT FOR UPDATE
, я обнаружил следующую интересную статью: https://hoopercharles.wordpress.com/2011/11/21/select-for-update-in-what-order-are-the-rows-locked/
В статье доказывается, что Oracle ведет себя иначе, чем MySQL и PostgreSQL, выполняя блокировки строк (TX) вДоступ к строкам заказа осуществляется не в том порядке, в котором они были получены (т.е. не в порядке, указанном ORDER BY
).
В моем сценарии запроса A указан PK таблицы в предложении Where и запросе Bтолько индексированный FK.Оба имеют доступ к более чем 500 строкам.Я понимаю, что если доступ осуществляется через индексированный FK, мы легко получаем другой порядок блокировок TX по сравнению с доступом через PK, что может привести к взаимоблокировке.
Если оба запроса используют только PK, это порядокTX блокирует детерминированный?Т.е. могу ли я быть уверен, что для двух SELECT FOR UPDATE
запросов с большими IN
условиями для PK невозможны тупики?Колонка PK индексируется, никогда не изменяется и монотонно увеличивается.
Я знаю, что в таких случаях обычно используют предложение NOWAIT
, но я по-прежнему заинтересован, можно ли решить проблему без такой илине.Спасибо.