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


-----Mensagem original-----
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
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 getLocalTransaction.

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.

WDYT?


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.

thanks
david jencks

Cheers, hammett




Reply via email to