On Mon, Apr 19, 2010 at 10:33 AM, Guy Rouillier <guyr-...@burntmail.com>wrote:
> I haven't been following this thread closely, but with JBoss at least, you > have the option of configuring datasources as no-transaction: > no-tx-datasource. With this type of datasource, you are free to call commit > and rollback yourself. With container-managed transactions, you should not > be calling commit or rollback. I've erroneously done so, and JBoss > generates an error saying that these methods are illegal on a container > managed transaction. > I agree, commit()/rollback() should not be called on the container managed connections. > > 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. > Only when the EJB method completes does the container do the commit or > rollback and then returns the connection to the pool as available for use. > > 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. Best, Adi -- Acciente, LLC Systems Architecture and Software Design www.acciente.com www.inductionframework.org