You did the right thing... iBATIS transaction managers are meant to be easy to implement yourself.
That said, this was a matter of constant debate back in the good old days when none of the standards were implemented consistently. I'm still not sure if they are. Some app servers would complain if iBATIS closed the connection, because if some downstream process needed a connection, theoretically it was supposed to use the same one (which would be closed by that time). I think the trick is to ensure that you're using a container managed DataSource. Are you retrieving a DataSource configured by GlassFish from a JNDI context (in other words, a container manged DataSource)? Or are you just using the iBATIS built-in SimpleDataSource? I would expect a container managed DataSource to lazily initialize a connection for any one worker thread, and continue to provide that same connection to any requester for that particular DataSource. Then I'd expect it to close that connection at the end of the entire workflow. Does anyone know if the spec specifies this? Cheers, Clinton On Sun, Apr 18, 2010 at 2:31 PM, Adinath <adin...@acciente.com> wrote: > 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? > Thanks, > Adi > > -- > Acciente, LLC > Systems Architecture and Software Design > > www.acciente.com > www.inductionframework.org >
