Будет ли обнаружена сделка OptimisticLockingException ruin db?

Question

Если я открою транзакцию и поставлю код, потенциально собирающийся выбросить OLE в блок try-catch, мне придется перезапустить транзакцию? Мой ответ да, но я не могу найти никаких подтверждений там ...

Мой код в основном выглядит следующим образом:

//start a hibernate transaction here 
try 
{ 
    //do things that are very likely to throw OLE 
} 
catch (Exception exc) 
{ 
    //just log it and do nothing else 
} 

//do something else that needs a hibernate session here (*) 

Так что, когда я в (*), это похоже, мне нужно будет проверить, активна или нет транзакция?

Answer 1

От: http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/transactions.html#transactions-demarcation-exceptions

Если сессия генерирует исключение, в том числе любой SQLException, немедленно откатить транзакцию базы данных, вызовите Session.close() и отбрасывать экземпляр Session. Некоторые методы сеанса не будут оставить сеанс в согласованном состоянии. Никакое исключение, вызванное Спящий режим может рассматриваться как подлежащий возмещению. Убедитесь, что сеанс будет закрыт вызовом функции close() в блоке finally.

И от: http://docs.oracle.com/javaee/6/api/javax/persistence/OptimisticLockException.html

Брошенный поставщика сохраняемости при возникновении оптимист блокировки конфликта . Это исключение может быть выбрано как часть вызова API, флеш или в момент фиксации. Текущая транзакция, если она активна, будет , обозначенная для отката.

Итак, да, вы должны закрыть сеанс, а затем повторите попытку.

Answer 2

Это выдержка из того, что вы можете найти в спецификации JPA относительно OptimisticLockException:

• проверка версии делается при записи изменений в БД, следовательно, за исключением , как правило, брошенные во время фиксации
• это всегда приводит к тому, что транзакция помечена для отката
• , если вы хотите, чтобы поймать и обработать исключение, вызов Flush(), чтобы заставить DB пишет произойти ранее
• исключение предоставляет API, чтобы вернуть объект, вызвавший исключение
• это, как правило, обрабатывается освежающим/перезагрузки несвежих объектов и повторной попыткой сделки

Для полноты картины, вот копия соответствующий раздел из спецификации:
(Я не могу указать конкретную ссылку, поскольку документ доступен только в формате .pdf here).

3.4.5 OptimisticLockException

Провайдеры могут откладывать запись в базу данных до конца транзакции, если это согласуется с настройками режима блокировки и режима очистки. В этом случае оптимистическая проверка блокировки может не произойти до момента фиксации, а исключение OptimisticLockException может быть выбрано на этапе «до завершения» фиксации. Если исключение OptimisticLockException должно быть обнаружено или обработано приложением, метод flush должен использоваться приложением для принудительной записи базы данных. Это позволит приложению захватывать и обрабатывать оптимистичные исключения блокировки.

Функция OptimisticLockException предоставляет API для возврата объекта, который вызвал исключение исключения. Ссылка на объект не гарантируется при каждом появлении исключения, но должна предоставляться всякий раз, когда поставщик по сохранению может ее предоставить. Приложения не могут полагаться на доступность этого объекта.

В некоторых случаях исключение OptimisticLockException будет свернуто и завершено другим исключением, таким как RemoteException, когда границы VM пересекаются. Объекты, на которые можно ссылаться в завернутых исключениях, должны реализовывать Serializable, чтобы маршаллинг не прерывался.

Исключение OptimisticLockException всегда вызывает маркировку транзакции для отката.

Обновление объектов или перезагрузка объектов в контексте новой транзакции, а затем повторная попытка транзакции является потенциальным ответом на исключение OptimisticLockException.