JDBC и вопрос об избежании тупиков (Основной) - PullRequest
4 голосов
/ 21 июля 2010

Я использую JDBC (через Spring JDBCTemplate) для доступа к небольшому количеству таблиц в базе данных.Хотя у меня еще ничего не происходило, меня беспокоит возможность тупиковой ситуации.

У меня сложилось впечатление, что существует способ указать порядок блокировки для запросов, которые обращаются к нескольким таблицам, чтобы избежать тупиков,но я не знаю, является ли это типом вещей, которые настраиваются на уровне БД при создании моих таблиц, или я должен что-то делать явно с моими запросами JDBC.

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

Спасибо.

1 Ответ

5 голосов
/ 21 июля 2010

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

Яне знаю, как JDBCTemplate управляет транзакциями, но соединение JDBC по умолчанию не транзакционное.Как только вы установите Connection#setAutoCommit() на false (или сконфигурируете его по умолчанию), транзакция начнется и завершится, когда вы вызовете Connection#commit().

Чтобы избежать взаимных блокировок, правило № 1 не позволяет смешивать SELECT с операторами INSERT/UPDATE/DELETE в одной транзакции.Когда смешивание является - на первый взгляд - обязательным, тогда вы должны хотя бы попытаться переписать его в один / вложенный оператор.Это часто просто возможно.Таким образом, вам не нужно выполнять эти запросы в транзакции.

Кроме того, некоторые базы данных, такие как PostgreSQL и Oracle, могут автоматически определять взаимоблокировки и автоматически откатывать одну из транзакций, обычно ту, которая была инициирована позже.В конце JDBC вы получите конкретный SQLException для этого.

...