jboss-dev-forums

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: Where should UserTransaction live?

[<ad...@jb...>]

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????

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875461#3875461

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875461

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: Where should UserTransaction live?

[<sco...@jb...>]

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.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875468#3875468

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875468

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: Where should UserTransaction live?

[reverbel <nu...@jb...>]

"ad...@jb..." wrote : 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.)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875601#3875601

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875601

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: Where should UserTransaction live?

[reverbel <nu...@jb...>]

"ad...@jb..." wrote : 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.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875605#3875605

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875605

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: Where should UserTransaction live?

[reverbel <nu...@jb...>]

"sco...@jb..." wrote : 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.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875607#3875607

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875607

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: Where should UserTransaction live?

[<ad...@jb...>]

"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.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875662#3875662

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875662