Лучший подход для преодоления возможного тупика с JDBC - PullRequest
Новая
       15

Лучший подход для преодоления возможного тупика с JDBC

0 голосов
/ 07 мая 2019

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

Я выучил несколько советов, как это сделать меньше , но неникогда, поэтому я обеспокоен правильной обработкой этого.Итак, допустим, что мы обращаемся к базе данных через JDBC.

Я не нашел никаких ссылок на обработку взаимоблокировок ни в документации , ни в официальных примерах какони просто откатываются (или выводят и исключение, если это невозможно): 

} catch (SQLException e ) {
        JDBCTutorialUtilities.printSQLException(e);
        if (con != null) {
            try {
                System.err.print("Transaction is being rolled back");
                con.rollback();
            } catch(SQLException excep) {
                JDBCTutorialUtilities.printSQLException(excep);
            }
        }
    }

Как я понял, читая документацию, если метод executeUpdate() находит тупик, он не повторяет попытку

Поиск различных решений Я нашел этот подход , который оборачивает все это в цикл со счетчиком и сном между каждой попыткой .

Итак, мои вопросы здесь таковы:

  1. Обрабатывает ли JDBC каким-либо образом взаимоблокировки, кроме генерации исключения?Любая библиотека на любом языке (по крайней мере, по желанию) повторяет запрос?
  2. Как бы вы справились с этим в сценарии, чувствительном к тупикам, с реализацией JDBC?
  3. Вы предотвращаете это в своем пользовательскомметоды доступа к базе данных?Кроме того, они у вас есть или вы просто используете строки по умолчанию при каждом доступе к базе данных?
  4. Почему ядро ​​базы данных не перезапускает запрос жертвы, когда необходимые строки разблокируются?

РЕДАКТИРОВАТЬ: Я нашел это в Документация MySQL :

Всегда будьте готовы повторно выполнить транзакцию, если она завершится неудачно из-за тупика.Тупики не опасны.Просто попробуйте еще раз.

Что предлагает обрабатывать код приложения.

Есть мысли?Заранее спасибо.

1 Ответ

1 голос
/ 07 мая 2019

Хотя уменьшение взаимоблокировок может иметь определенное значение, в правильно спроектированной системе взаимоблокировки должны быть исключительно редкими.Вы упомянули, что изучали несколько советов о том, как их избежать, но вот мой собственный список:

  • Во многих системах существуют объекты / сущности верхнего уровня, которые вы всегда сначала блокируете перед обновлением своих дочерних таблиц.Например, в системе обработки заказов может быть много разных таблиц для хранения данных, но вы всегда пытаетесь сначала заблокировать объект заказа верхнего уровня.
  • В более общем случае, если весь код, обращающийся к базе данных, всегда блокирует объектыв том же порядке, тогда тупиков не будет.(Например, если одно соединение блокирует строки из таблиц A и C в указанном порядке, а другое блокирует A, B и C по порядку, тупиковая блокировка невозможна независимо от времени этих блокировок.)
  • Системы могут также быть разработаны, чтобы устранить большинство блокировок.Например, если данные добавляются, а не редактируются, блокировка не требуется.
  • В базе данных NoSQL все связанные данные обычно хранятся в одном объекте.Блокировка не требуется и может даже не поддерживаться базой данных.

Если вы разрешите пользователям произвольный доступ для записи в базу данных, то, конечно, вы не сможете контролировать факторы, которые приводят к взаимоблокировке.Но я никогда не видел серьезной системы, которая позволяла бы это.

Поэтому вместо того, чтобы беспокоиться о реагировании на тупики, все ваши энергии должны быть потрачены на то, чтобы полностью их избежать.Когда вы видите тупик, вы обнаруживаете ошибку в вашей системе, которая позволила ему произойти.

...