Непонятно, что именно спецификация 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
" раз?