geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [jira] Commented: (GERONIMO-161) LocalXAResourceInsertionInte rceptor could use XAResource implementation
Date Tue, 06 Apr 2004 19:00:36 GMT

On Tuesday, April 6, 2004, at 10:16 AM, Hamilton Verissimo de Oliveira 
(Engenharia - SPO) wrote:

> -----Mensagem original-----
> De: []
> Enviada em: terça-feira, 6 de abril de 2004 14:00
>> Please explain why this patch is a good idea.
> Think about JdbcTransactionalManagedConnection, the getLocalTransaction
> should return null (or an exception) as we don't want anyone to mess 
> with
> transaction that should be handled only by XAResource, right?

no.  section 7.13.1
XATransaction—The resource adapter supports both resource manager local
and JTA transactions by implementing the LocalTransaction and XAResource
interfaces. The requirements for supporting the XAResource-based 
contract are
specified in Section 7.6 “XAResource-based Transaction Contract”.

In other words,  if an adapter supports getXAResource it MUST support 
> If not, then JdbcTransactionalManagedConnection.getLocalTransaction 
> should
> return a wrapper to XAResouce and this will be wrapped again by
> LocalXAResourceInsertionInterceptor. Doesn't make sense to me  :-)

I don't see why a jdbc LocalTransaction should use XAResource.  I would 
think it would use java.sql.connection.setAutocommit for begin and the 
connections commit/rollback methods.

I think that, for an adapter that supports xa, if you want to use only 
local transactions, you should explicitly say this by deploying it with 
the useLocalTransactions flag set to true.  This is completely 
unambiguous and does not try to second guess the users intentions.  
This is what I implemented and I don't see any reason to change it yet.

I haven't looked very hard at your openejb patch yet, but I think that 
supplying separate wrappers for non-xa and xa jdbc implementations is a 
good idea.  I think that trying to unify everything in one 
implementation will be too hard to maintain.  Such wrappers can share 
most of the classes.  I'll look harder at your patch though.

david jencks
> Cheers,
> hammett

View raw message