Okay, I've looked around. It is really hard to find the way it's "supposed" to work, but I don't think it matters. There's more than enough empirical evidence (both in iBATIS 2 and Adinath's custom implementation). So I've added the close to the ManagedTransaction. It will log but otherwise ignore exceptions thrown by close(), to deal with unexpected states (and re-throwing an exception from close could hide a more important root cause exception).
The funny thing is that I even had a unit test asserting this behavior, so I must have done it at some point for a reason. I just hope it wasn't a very good reason. ;-) It's also funny that it wasn't found in 10 betas... which either implies that not many people use managed transactions, or that some app servers behave as I thought they would. I'm going to recommend a re-build before we take iBATIS 3 to GA, so the iBATIS release we'll vote on will probably be 3.0.1. Cheers, Clinton On Mon, Apr 19, 2010 at 7:54 PM, Guy Rouillier <guyr-...@burntmail.com>wrote: > On 4/19/2010 2:07 PM, Adinath wrote: > >> >> Regarding your thoughts about a smart resource manager, that is >> indeed what happens. Remember that datasource may be retrieved and >> closed any number of times during the processing of a single EJB >> method. During the execution of single EJB method, the container is >> required by the spec to return the same physical connection each >> time getConnection() is invoked, so that all database activity >> within that method (which can of course call other methods) is >> guaranteed to be within the same transaction. >> >> >> What about a method in bean A that call a method a different bean say B, >> does the spec require that B gets the same underlying connection? In >> GlassFish I suspect I am getting completely independent connections, I >> need to verify this. >> > > Should return the same connection. One EJB is allowed to invoke another, > and the container is supposed to identify that it is already in a > transaction and not start a new one. > > > Since iBATIS can't possible determine that it is being used in a >> container-managed transaction, if you want to support that, I would >> think the only possibility is to provide an optional parameter in >> the data source configuration to indicate that. In such cases, >> iBATIS should probably no-op commit and rollback. >> >> >> IBATIS does not need a config parameter, you can do this by implementing >> a simple transaction factory. >> > > I'm not following you. iBATIS is told to use a JNDI datasource X. How can > it determine if it is running (e.g.) in a JBoss environment with a > no-tx-datasource, in which case it needs to do commit() and rollback() > before closing the connection? Or if it is running in a JBoss environment > with a local-tx-datasource, in which case it cannot do a commit() or > rollback() before closing the connection? > > Are you suggesting that in the second case, the programmer can supply a > do-nothing transaction manager? That approach imposes that requirement on > everyone who uses iBATIS. Certainly just supplying a param makes life > easier for a lot of people. > > > -- > Guy Rouillier > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org > For additional commands, e-mail: user-java-h...@ibatis.apache.org > >
