Кто-нибудь использует iBATIS 3 в качестве своей среды хранения в контейнере EJB? Недавно я начал создавать новую систему, для которой я выбираю EJB 3.1 (версия EJB на самом деле не имеет отношения к этому вопросу) в качестве среды моего приложения, а iBATIS 3 (эта версия актуальна!) В качестве среды хранения. Моя бизнес-логика реализована в сессионных компонентах EJB 3.1, которые используют iBATIS 3 для доступа к данным. Я работаю на GlassFish v3)
Моя проблема с этим стеком - управление транзакциями. Я решил свою проблему, написав несколько простых интеграционных кодов, но я был немного удивлен, что мне пришлось это сделать. Поэтому я решил опубликовать это, чтобы увидеть, столкнулись ли другие с этим, и если да, то как они решили проблему.
Мое требование - чтобы iBATIS 3 прозрачно использовал транзакцию EJB (обычно определяемую декларативно) в методе сессионного компонента. iBATIS 3 предоставляет 2 фабрики транзакций JdbcTransactionFactory и ManagedTransactionFactory, и я обнаружил, что ни одна из них не работает правильно в среде EJB (и, глядя на источник iBATIS, становится ясно, почему он не работает).
JdbcTransactionFactory не подходит, так как я хочу, чтобы любые вызовы sqlSession.commit () или sqlSession.rollback () игнорировались. Поэтому я подумал, что хорошо, что я должен использовать ManagedTransactionFactory, так как он вызывает любые вызовы sqlSession.commit () или sqlSession.rollback (), но также вызывает sqlSession.close () для , а не для закрытия соединение, которое iBATIS открыл из DataSource в sqlSession.open () (DataSource - это управляемый контейнером объект DataSource, который я предоставляю iBATIS). Это приводит к тому, что GlassFish исчерпывает свой пул подключений, и приложение перестает работать.
Итак, я написал новую реализацию TransactionFactory, EJBTransactionFactory, которая заставляет sqlSession.commit () или sqlSession.rollback () ничего не делать, но закрывает соединение, когда вызывается sqlSession.close ().
Я подозреваю, что другие люди столкнулись с этим, как вы решили это?