Clinton,
On Sun, Apr 18, 2010 at 2:45 PM, Clinton Begin <clinton.be...@gmail.com>wrote:
> You did the right thing... iBATIS transaction managers are meant to be easy
> to implement yourself.
>
Yes, they are easy to implement!
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?
>
Yes I am using using a container managed datasource (GlassFish v3 managing a
DB2 v9.7 connection), looked up via JNDI. I create the iBATIS session
factory using SqlSessionFactoryBuilder and the related classes (i.e. no XML
config file).
I
> 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.
>
My experience with GlassFish is that the connection needs to be closed to be
returned to the pool.
With GlassFish I wrote a set of tests and established that if you call
commit() on a JDBC connection returned by the container managed datasource
it causes an commit (thru to the driver), defeating the EJB transaction.
There are 2 other issues I ommitted in my original post, for clarity. I
suspect these 2 issues have nothing to do with IBATIS, but I am just sharing
FYI (just in case).
*Issue #1*
In the close() method of my custom iBATIS transaction class I would
transiently (about every 4 times) get IllegalStateException with
"state.isBusy() : false" in the message when I call connection.close(). Some
posts pointed that this happens when the connection is already closed. But I
have verified using the debugger that this does not apply, the connection is
open and isClosed() returns false. The fix for now is to catch the
IllegalStateException the close() and ignore it! :(
*Issue #2*
The other issue is rather unnerving, I am reluctant to share it since it is
a little winded, but thought perhaps it may help someone else. This too I
suspect has nothing to do with iBATIS. It is as follows:
- there is a stateful session bean (sfsb) A that has a reference to another
sfsb B
- there is a method in sfsb A, say methodOfA, which inserts a row using
iBATIS
- there is a method in sfsb B, say methodOfB, which inserts a row using
direct JDBC
- methodOfB() also uses a container managed DataSource to retrieve a
connection and does connection.close() before returning
- now the logic in methodOfA() looks like below:
public void methodOfA()
{
session = sessionFactory.openSession()
boolean commit = false;
try
{
mapper = session.getMapper( UserMapper.class);
someID = beanB.methodOfB();
// set value for user
user = new User();
user.setOtherStuff() ...
user.setSomeID( someID );
// insert row for new user
mapper.insertUser( user );
commit = true;
}
finally
{
session.close();
if ( ! commit )
{
sessionCtx.setRollbackOnly();
}
}
}
The issue here is that if I set a debug breakpoint at the line with
mapper.insertUser(
user ),I sometimes see the update by referenceToB.methodInB() get commited
to the database!! (checked via a DB2 SQL console) This happened late Friday
and I have not had a chance to look at since. I think the culprit here is
GlassFish, I suspect that this happens only during debugging (need to verify
this).
On a final note, I have used iBATIS 2 on a previous project and iBATIS 3 on
the current one. Even with IBATIS 2 I thought it was an incredible piece of
work, well-thought out and a pleasure to use. Especially love the support
for dynamic SQL, and the type handler callbacks. Excellent work!
Best,
Adi
--
Acciente, LLC
Systems Architecture and Software Design
www.acciente.com
www.inductionframework.org
