Where should UserTransaction live?

[reverbel]

A modularization issue... I have some (still uncommitted) code that uses the DTM to implement UserTransaction over JBoss remoting. The code is very simple and consists on just two classes:

org.jboss.tm.remoting.client.ClientUserTransaction
org.jboss.tm.remoting.client.ClientUserTransactionObjectFactory

Those classes are similar to the corresponding ones in package org.jboss.tm.usertx.client (in the server module) an in package org.jboss.tm.iiop.client (in the iiop module). The object factory class checks if it is running in the server VM or not. If it is not running in the server VM, it creates a ClientUserTransaction. Otherwise it creates a ServerVMClientUserTransaction.

I placed the new classes in the server module, as the object factory depends on ServerVMClientUserTransaction, which is also in the server module. They would be better placed in the transaction module, but then the transaction module would be dependent upon the server module.

I don't know why ServerVMClientUserTransaction and the other usertx classes live in the server module. It looks like the transaction module would be the right place for them. At this point, however, we cannot move those classes, as this would break the compatibility with older clients.

So my options are:

(1) put the new classes in the transaction module and create a new dependency from the transaction module on the server module, or

(2) leave the new classes in the server module, together with ServerVMClientUserTransaction, or

(3) put the new classes in the transaction module and create a copy of ServerVMClientUserTransaction in the transaction module.

Option (1) sounds like a bad idea to me, so it's going to be either (2) or (3). Does anybody care?

Francisco

[starksm64]

(3a) put the new classes in the transaction module and move the ServerVMClientUserTransaction to the transaction module.

No code should broken by this as all that is happening is that the ServerVMClientUserTransaction will live in a different jar.

[reverbel]

You're right, I've made a confusion between jar files and Java packages. Since the move won't break anything, I can move to the transaction module the remaining usertx classes as well.

Thanks,

Francisco

[reverbel]

Some usertx classes have dependencies on other server module classes, so for now I have moved to the transaction module just the class ServerVMClientUserTransaction. The remaining usertx classes are still in the server module.

Francisco

[adrian.brock]

Your problem is that org.jboss.tm.remoting implementation
does not belong in the transaction manager module.

The transaction manager module exists independently of remote access or its
implementation details.
You should not be making/fixing this integration at this level.

In fact, the transaciton module needs to splitting up to separate the interfaces that define
the integartion points and the real implementations. And the rest of JBoss should
just use the interfaces/not the implementation.
I remember discussing this before in an earlier thread????

[starksm64]

You are arguing for a transaction remoting module that combines the transaction and remoting codebases. That is fine. I'm sure the issue Francisco is having is reconcilling the tangled mess that currently exists as he is trying to prototype. Why not fix the dependencies/structure in the new build and then move the org.jboss.tm.remoting implementation and related to it.

[reverbel]

The transaction manager module exists independently of remote access or its
implementation details.

Yes and no.

Yes, the core transaction manager should not depend on implementation details of modules that provide remote access to it. The code in CVS satisfies this requirement. The transaction module should still compile if you delete everything under tm/remoting but the subdir tm/remoting/interfaces.

No, the transaction manager must be aware of remote access, as it must know a set of interfaces implemented by remote access providers. It must keep references to remote resources (which implement a Resource interface), a reference to a parent coordinator (which implement a Coordinator interface), etc. It must call methods on remote Resource and Coordinator objects at appropriate times.

Remote access interfaces currently live in org.jboss.tm.remoting.interfaces. Two remote access providers implement those interfaces: a remote access provider based on JBoss remoting and dynamic proxies, which consists of the remaining classes under tm/remoting, and an IIOP/OTS-based one, which lives in org.jboss.tm.iiop (in the iiop module).

Perhaps you are simply saying that the code in org.jboss.tm.remoting.interfaces should be moved to another Java package? (I have actually considered creating a new package org.jboss.transaction, which would contain interfaces implemented either by the core TM or by remote access providers.)

[reverbel]

In fact, the transaciton module needs to splitting up to separate the interfaces that define
the integartion points and the real implementations. And the rest of JBoss should
just use the interfaces/not the implementation.

Yes. At some point I want to make TransactionImpl implement a new interface org.jboss.transaction.TransactionBranch (or something like that), which would extend javax.transaction.Transaction. A similar thing would be done with the TxManager class. The new interfaces would express more clearly the contract between the core TM and the rest of the world, including the remote access providers to it.

[reverbel]

You are arguing for a transaction remoting module that combines the transaction and remoting codebases.

This would be very easy to do, it is mostly a jar packaging decision.

Right now the IIOP/OTS access to the core TM is already in the iiop module. We could do the same for the JBoss-remoting access to the TM, i.e., move org.jboss.tm.remoting to remoting module. The interfaces currently in org.jboss.tm.remoting.interfaces would remain in the transaction module.

[adrian.brock]

"reverbel" wrote:
[
No, the transaction manager must be aware of remote access, as it must know a set of interfaces implemented by remote access providers. It must keep references to remote resources (which implement a Resource interface), a reference to a parent coordinator (which implement a Coordinator interface), etc. It must call methods on remote Resource and Coordinator objects at appropriate times.

I'm saying these should be core the interfaces. Whether the implementations actually
do remote work or are optimized for local tx management is a deployment decision.

What I'm really after is the ability to plugin any TM and if it doesn't support certain
features like Tx propogation over Remoting or the JCA XATerminator then there is a
standard mechanism to integrate those features (or not if they are not required,
e.g. mocks for testing purposes).
This might be "pie in the sky" but it is an ideal we should aim for, even if it is not
entirely attainable.

That is how TransactionLocal works with a an implementation based on tx
synchronization if the transaction manager does not directly support it.