ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Butler <jeffgbut...@gmail.com>
Subject Re: Transaction management in iBATIS 3 inside an EJB (3.1) container
Date Sun, 18 Apr 2010 22:54:58 GMT
AFAIK, it's always been required to close the connection to return it
to the connection pool.  iBATIS2's EXTERNAL transaction manager does
close the connection.  How else would the container know when we're
finished with the connection?

The problem I remember was with WebSphere when we didn't call commit()
before closing the connection with the JNDI transaction manager - that
caused a problem with WebSphere connection pooling and we had to
introduce the "commitRequired" property.

I did a quick look for EJB 3.1 and this:


It seems to imply that we still have to call close to return the
connection to the pool.

Jeff Butler

On Sun, Apr 18, 2010 at 4:45 PM, Clinton Begin <clinton.begin@gmail.com> wrote:
> 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 <adinath@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

To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org

View raw message