Тупиковые блоки будут зависеть от транзакций не по статическому коду. В Oracle нет понятия «BEGIN TRANSACTION», поэтому статический анализатор не знает, что такое начальная точка транзакции. Гипотетически, анализатор может быть записан таким образом, что если ему задан исходный оператор SQL или PL/SQL, он может отслеживать все возможные пути выполнения и определять, какие таблицы были подвергнуты операциям update/delete/insert/merge в каком порядке. Затем вы можете «сравнить» два (или более) результата этого и определить, есть ли там, где таблицы обрабатываются в другом порядке (например, TAB_A, затем TAB_B в одном и TAB_B, затем TAB_A в другом). Я подозреваю, что это вызовет много ложных срабатываний.
В Oracle выбор не блокируется (кроме SELECT ... FOR UPDATE). Таким образом, взаимоблокировки возникают только при обновлении данных и только тогда, когда две параллельные транзакции пытаются обновить одни и те же строки.
Мне просто интересно, как инструменты, такие как Coverity/Klocwork/FindBugs, могут найти взаимоблокировки (не все конечно и с ложными срабатываниями, но намного лучше, чем ничего) в коде C++/Java, где количество путей выполнения больше на два порядка ... –
Без использования данных нет способа узнать, какие запросы выполняются в базе данных. Если вы ограничиваете себя хранимыми процедурами, нет способа узнать порядок, в котором они вызываются без использования данных. Это отличается от C++ или Java-программы, где у вас есть гораздо больше информации о том, как будет работать программа. – Andomar