Я использую Glassfish 3.1.1 с базой данных Oracle и столкнулся с проблемой, когда транзакции не откатываются, а пока только в одной конкретной среде. То же приложение работает, как и ожидалось, на других машинах. Однако это влияет на два отдельных домена Glassfish на одном компьютере.
В уязвимой среде у меня есть похожие результаты как с транзакциями, управляемыми контейнером (CMT) внутри EJB, который генерирует исключение RuntimeException, так и с транзакцией, управляемой бином (BMT) с UserTransaction#rollback().
В обоих случаях основная проблема заключается в том, что JDBC-соединение каким-то образом все еще установлено с autoCommit = true, даже если выполняется транзакция JTA.
Мой тест EJB / CMT выглядит так:
@Named
@Stateless
public class TransactionTest {
@PersistenceContext
EntityManager entityManager;
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void rollbackTest() {
Foo foo = new Foo();
entityManager.persist(foo);
entityManager.flush();
throw new RuntimeException("should be rolled back");
}
}
и мой тест BMT / UserTransaction выглядит так:
public void rollbackUtxTest() throws Exception {
utx.begin();
Foo foo = new Foo();
entityManager.persist(foo);
entityManager.flush();
utx.rollback();
}
Когда я вызываю любой из этих методов, INSERT INTO FOO фиксируется, даже если транзакции откатывались.
Чего мне не хватает - возможно, у меня нет пула соединений / источник данных не настроен правильно?
Я использую OracleConnectionPoolDataSource в качестве имени класса источника данных. Что мне нужно сделать, чтобы подключения к моей базе данных участвовали в транзакциях JTA?
ОБНОВЛЕНИЕ 1 Первоначально я думал, что это проблема с OracleConnectionPoolDataSource, но оказалось, что это не коррелирует. Та же самая конфигурация пула работает в одной среде, но не в другой.
ОБНОВЛЕНИЕ 2 Уточнено, что это не проблема EJB / CMT, а общая проблема JTA.
ОБНОВЛЕНИЕ 3 добавлена информация об автокоммите JDBC. Подтвердил, что файл persistence.xml правильный.