ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adinath <adin...@acciente.com>
Subject Transaction management in iBATIS 3 inside an EJB (3.1) container
Date Sun, 18 Apr 2010 20:31:21 GMT
Is anybody out there using iBATIS 3 as their persistence framework inside an
EJB container? I recently started building a new system for which I choose
EJB 3.1 (the version of EJB is actually irrelevant to this question) as my
app framework and iBATIS 3 (this version is relevant!) as my persistence
framework. My business logic is implemented in EJB 3.1 session beans that
use iBATIS 3 for data access. I am running on GlassFish v3)

My issue with this stack has been transaction management. I have solved my
problem by writing some simple integration code, but I was little surprised
I had to do this. So I decided to post this to see if others have run into
this and if so how they solved the problem.

My requirement is for iBATIS 3 to transparently use the EJB transaction
(typically defined declaratively) in the session bean method. iBATIS 3
provides 2 transaction factories JdbcTransactionFactory and
ManagedTransactionFactory and I found that neither one works correctly in an
EJB environment (and looking at the iBATIS source it is clear why it fails).

The JdbcTransactionFactory is inappropriate since I want any calls to
sqlSession.commit() or sqlSession.rollback() to be ignored. So I thought ok
I should use the ManagedTransactionFactory since it does cause any calls to
sqlSession.commit() or sqlSession.rollback() to be ignored, however it also
causes sqlSession.close() to *not* close the connection that iBATIS opened
from the DataSource in sqlSession.open() (the DataSource is a container
managed DataSource object I provide to iBATIS). This causes the GlassFish to
exhaust its connect pool and the application fails.

So I wrote a new TransactionFactory implementation, EJBTransactionFactory,
that causes sqlSession.commit() or sqlSession.rollback() to do nothing, but
*does close* the connection when sqlSession.close() is called.

I suspect other people have run into this, how did you solve it?

Acciente, LLC
Systems Architecture and Software Design


View raw message