-
1. Re: ClientUserTransaction and TxPropogation inefficiencies
You missed the big one, which is: It won't work with the JTS. Since the JTS is going to be a supported option shortly, we should probably figure out what we want to do about that :-)
-
2. Re: ClientUserTransaction and TxPropogation inefficiencies
"jhalliday" wrote:
You missed the big one, which is: It won't work with the JTS. Since the JTS is going to be a supported option shortly, we should probably figure out what we want to do about that :-)
What do you mean? UserTransaction is JTA not JTS.
The ClientUserTransaction is only a proxy to a real transaction on the server
so JTS is irrelevant for normal clients.
If there is a transaction manager on the "client" then we use
ServerVMClientUserTransaction which is just a wrapper for that JTA implementation.
UT.begin() -> TM.begin()
etc.
Of course whether/how that "client" will propogate the TPC to the real server
maybe an issue you need to resolve, but it is irrelevant whether
the transaction was started using the UserTransaction api or some
other use of the client's TM. -
3. Re: ClientUserTransaction and TxPropogation inefficiencies
> The ClientUserTransaction is only a proxy to a real transaction on the server so JTS is irrelevant for normal clients
Unfortunately not. If a normal (i.e. without ORB) client is using UT to communicate to a server and that server is switched from the JTA to the JTS, the client will break. Of course that may be a bug rather than a design issue.
Then there is the question of what the behaviour should be when the client is using RMI/IIOP rather than JRMP for transactional calls to the server. Should it need the JBossTS libraries, or should it continue to use UT? What if it wants to switch to JBossTS? Using either the JTA API or the CORBA API for transaction demarcation. -
4. Re: ClientUserTransaction and TxPropogation inefficiencies
"jhalliday" wrote:
> The ClientUserTransaction is only a proxy to a real transaction on the server so JTS is irrelevant for normal clients
Unfortunately not. If a normal (i.e. without ORB) client is using UT to communicate to a server and that server is switched from the JTA to the JTS, the client will break. Of course that may be a bug rather than a design issue.
Then there is the question of what the behaviour should be when the client is using RMI/IIOP rather than JRMP for transactional calls to the server. Should it need the JBossTS libraries, or should it continue to use UT? What if it wants to switch to JBossTS? Using either the JTA API or the CORBA API for transaction demarcation.
So you're saying the TPC obtained by UserTransactionSessionImpl is not usable
by the client when JTS is installed on the server?public Object begin(int timeout) throws RemoteException, NotSupportedException, SystemException { TransactionManager tm = getTransactionManager(); // Set timeout value tm.setTransactionTimeout(timeout); // Start tx, and get its TPC. tm.begin(); Object tpc = getTPCFactory().getTransactionPropagationContext(); // HERE !!!! // Suspend thread association. Transaction tx = tm.suspend(); // Remember that a new tx is now active. activeTx.put(tpc, tx); // return the TPC return tpc; }
In that case, it is a bug.
We probably need some new api to differentiate the two use cases
of getTPC().
1) When propogating calls to other servers
2) When retrieving a TPC usable by a client to control UTs. -
5. Re: ClientUserTransaction and TxPropogation inefficiencies
"jhalliday" wrote:
Then there is the question of what the behaviour should be when the client is using RMI/IIOP rather than JRMP for transactional calls to the server. Should it need the JBossTS libraries, or should it continue to use UT? What if it wants to switch to JBossTS? Using either the JTA API or the CORBA API for transaction demarcation.
We shouldn't need any current JBossTS code at the client side if the client code indirects through JTS. The client should simply interact with the Current pseudo-object, which we know can be wrapped by a UserTransaction. The current UserTransactions in JBossTS would pull in too much of the JBossTS code. What we had in HP (written by Malik) was a small UT implementation that called directly to Current (or maybe it was TransactionFactory, I can't remember, but in which case it would also be doing thread-to-transaction association). I'll dig around and see if I can still find that code, because it's definitely not in the JBossTS sources at the moment.