On Mon, Apr 19, 2010 at 8:15 AM, Clinton Begin <clinton.be...@gmail.com>wrote:
> Thanks Adinath. > > This will all help. Let's figure this out together. > > The odd thing for me is this. A typical transaction lifecycle (be it > global or otherwise would be: > > * Open Connection > * Do Work > * Commit or Rollback > * Close Connection (even if this implies a return to the connection pool) > > The problem with calling close on a connection that's globally managed is > that it changes the lifecycle to: > > * Open Connection > * Do Work > * >> Close Connection (even if this implies a return to the connection > pool) > * Commit or Rollback > > Now I suppose a smart resource manager controlling the transaction would > know better than to actually return the connection to the pool until the > worker thread is finished and the transaction is either committed or rolled > back, but I'm not entirely confident that all app servers are that smart. This was my exact dilemma, then I saw an article (which I cannot find now) that suggested in a managed environment connection.close() marks the connection for closing but does not actually return the connection to the pool until the transaction completes, at which point commit() or rollback() is called on the connection and the connection returned to the pool. This made perfect sense. I wrote a set of test cases that opened 2 JDBC connections from the managed datasource in a session bean and performed a row insert on each connection to a test table (same table for both inserts). The observation were consistent with the claim in the article. I observed the following (in the context of GlassFish v3): - the container commits the transaction (on both connections) on completion of the session bean (i.e. no connection.commit() needed) - committing the transaction on a connection in the code is "bad" (this was what I expected), since it overrides the EJB transaction - if setRollbackOnly() is called it rolls back updates made using both connections - my attempts to look inside the wrapped connection objects returned show no evidence that I am getting the same underlying connection handle > As you noted, glassfish doesn't even warn you when you call commit in a > managed transaction (most resource managers would throw an exception if > commit or rollback were called). I wouldn't be surprised if this is the > reason you're getting intermittent IllegalStateExceptions. > Yes the lack of an exception from GlassFish is a bummer, I am going to take a closer look at the GlassFish connection pool settings to see if they have a bearing on this behavior. I'm going to do a little more reading tonight on JEE 6 standard behavior to > see if there's one approach we can trust. > > The most empirical evidence of the proper behavior would be iBATIS 2, which > calls close. But I normally don't remove code without reason (although it > has happened ;-). > > I'll check into this tonight or tomorrow at the latest. > Thanks, it seems like I am able get everything working nicely with reliable transactions except in debug mode (incidentally I use IntelliJ IDEA Ultimate 95.54 EAP), but that is still unnerving. Will continue to look at this today and update this thread if needed. Appreciate the excellent feedback. Best, Adi -- Acciente, LLC Systems Architecture and Software Design www.acciente.com www.inductionframework.org
