>
> Thread association is an implicit system level way to carry a transaction or for
>that matter any other object (think security). Its sole purpose in life is to pass
>*random* information through a typed interface. e.g. the association of the tx to the
>thread permits us to read that information behind the "wall" of the API, even if the
>API doesn't explicitely declare that information.
>
> This is a system construct, superior for example to the lame duck aka JINI that
>calls for explicit coding of tx in the API doSomething(..., TX).
>
> FINE, however we have a superior way to do it in JBoss, we can pass the transaction
>information THROUGH the API in the "INVOCATION". THEREFORE building anything that
>relies on the system presence of the association assumes that all parties are doing
>the right thing with that association, which is not the case here.
>
> We work from the tx in the message.
>
> The rest is TM specific quirks
This seems not precise. Indeed, once a MethodInvocation is constructed,
the tx context is passed along and the system is aware about it. There is
one place where the tx context is not taken from the MethodInvocation,
namely, when the MethodInvocation itself is created (In
GenericProxy.getTransaction() {
return (tm == null) ? null : tm.getTransaction();
}
So, after we come back to the Proxy from an invocation we better preserve
the threadTx, because the next time around it is going to get passed as
part of MI. The problem I was experiencing is with non-preservation of
null transaction.
>
> In the early EJBoss I separated these calls into tx.commit/tx.rollback and then
>"suspendAssociation" "resumeAssociation", because that semantic is clearer than the
>fuzzy "if you commit with this or that we dis-associate and what not".
>
> At this point a simple way to solve this is to explicitely dis-associate thread if
>the tx is demarcated (commit/rollback)
>
I remember this code but to integrate any
javax.transactions.TransactionManager, we had to do away with it and be
JTA-compliant.
>
> The Transacation manager interprets the fuzzy "resume" however it wants, resume
>should only be an association of the tx to the thread and basta, nothing else, it
>should not *think* about the status of the tx at all i have argued in the past with
>OLE that THIS IS NOT A LIFECYCLE EVENT ON THE TRANSACTION, CLEARLY CLEARLY CLEARLY,
>SO THE TM SHOULD NOT ****THINK**** ABOUT THE TX IT SHOULD JUST ****RESUME
>ASSOCIATION****.
>
> Sorry to talk all in cap my keyboard got stuck.
>
> > So, the lesson is,
>
> JTA/TM is a crappy spec interpreted left and right ?
>
> I should be on that commitee writing the transaction spec and I would clean up this
>clear mess.
Well, I am not going to try to make every TM-vendor be compliant to a
non-existent spec of MF :)
Just trying to make the interceptor more robust to various spec
interpretations
>
> >the thread has to leave the
> > interceptor with exactly
> > the same tx association it came in. Because threadTx
> > can be null, we don't
> > always resume threadTx, so if threadTx was null when
> > the thread came in,
> > it must be null when the thread leaves, so if the
> > transaction manager does
> > not clean tx thread association through
> > Transaction.commit() and
> > Transaction.rollback(), it must be cleaned by the
> > interceptor through
> > tm.suspend() to make threadTx null again.
>
> Yes that would work, always dis-associating the thread if commited/rollback seems
>like a good idea, making that call explicit as opposed to buried in the
>interpretations of the spec is a good idea,
>
> > The changes to the interceptor are trivial (always
> > call tm.suspend, even
> > if committing or rolling back the new transcation).
>
> No, be careful there cowboy do you really want to call suspend() (in
> the dis-association sense) if your transaction is not commited? Could
> be. In jboss it is the recommend way because we pass the information
> explicitely, in integration with other parties... I don't know, if
> they take our information ok if not they will rely on the system level
> association and you should preserve the association.Think about the
> EJB spec it actually SAYS you should resume association if the tx is
> still there.
>
>
> in clear ONLY suspend the system association IF you commited or
> rolledback yourself (as opposed to the wrong "all the time *even if*
> rollback".
>
> Do we have agreement?
I think so, this is the snippet from TX_REQUIRED
try {
return invokeNext(remoteInvocation, mi, newTransacation != null);
} finally {
if (newTransaction != null) {
if (newTransaction.getStatus() == Status.STATUS_MARKED_ROLLBACK) {
newTransaction.rollback();
} else {
newTransaction.commit();
}
mi.setTransaction(oldTransaction);
}
/*
here the old code has
else {
tm.suspend();
}
And I propose to get rid of 'else' and just:
*/
tm.suspend();
This should remove the tx association as it used to [b]_plus_[/b] just in
case, if the TM does not disassociate in tx.commit() and
tx.rollback() this would do explicit disassociation.
>
> > Also, in
> > TX_SUPPORTS, there has to be
> > if (oldTransaction != null)
> > guard befor tm.resume(oldTransaction) is called,
> > otherwise Tyrex is pissed
> > off :)
>
> Tyrex is a crappy TM, I would rather see FastTM extended to DistributedTM in JBoss.
>
Don't know about any other TM, what are the URLs (or this is 'vaporware')?
I integrated Tyrex for pure research purposes since I could not get my
hands on any other stable open-source DTM, so don't care at the moment as
long as it works.
Anatoly.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
