2013-11-21 2 views
1

Непонятно, что именно спецификация JPA должна произойти, если ManagedType#getSingularAttribute(String) выбрасывает IllegalArgumentException. Похоже, что очень осторожно излагать именно те случаи, когда любая существующая транзакция должна быть отменена, и такое положение дел, похоже, не является среди них. (Этими положениями обычно являются операции EntityManager.) Таким образом, мое положение по умолчанию состоит в том, что не должно происходить откат транзакций. Это верно?Будут ли исключения, брошенные из ManagedType # getSingularAttribute (String), отменить транзакцию? Что изнутри SLSB?

(Для полноты, если являются в одном из состояний дел, перечисленных в спецификации JPA, то просто бросание из (к примеру) RuntimeException является то, что помечает транзакцию для отката. Ловля и игнорируя его, не позволяет вам отключиться.)

Итак, мы дома бесплатно, не так ли?

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

В таблице 16 спецификации EJB 3.1 говорится (интерпретируется и перефразируется), что если бизнес-метод встречает системное исключение, транзакция откатывается назад. Это говорит о том, что это происходит в контейнере catch времени (т. Е. Только если контейнер видит рассматриваемое системное исключение —, подразумевая, но явно не заявляя, что если вы его заранее поймаете и справитесь с ним, как будто ничего не произошло. «throws» откат времени в спецификации JPA).

Так что, если я нахожусь в (EJB 3.1) сессионного компонента, в сделке JTA, и я делаю это:

boolean attributeExists = true; 
try { 
    jpaManagedType.getSingularAttribute(attributeName, attributeJavaType); 
} catch (final IllegalArgumentException noSuchAttribute) { 
    attributeExists = false; 
} 

... должна моя JTA сделка все еще фиксации никому? Или требуется откат на IllegalArgumentException "throws" раз?

ответ

0

JTA сделка будет подлежащей передаче. Контейнер ищет RuntimeExeption только для методов EJB - с использованием tx-перехватчиков