Hi,
marc fleury wrote:
> |> Well at least we are further than we were with Rickard :)
> |> Ok this sentence also clearly shows the separation between "suspend" and
> |> suspend Association. Many thread can be associated to a
> |transaction and you
> |> can "suspend" the association on each one individually. Suspend on the
> |> "transaction" would suspend teh "Global" transaction and of
> |course propagate
> |> to the other "local" associations.
> |>
> |> "suspend" is a global notion on the "global transaction" whereas
> |association
> |> doesn't affect teh liveliness of the TM just the local VM association.
> |
> |I guess we should be careful about the definition
> |of "global" here. For a distributed TM this could
> |have two meanings:
> |- Everything on all nodes that know about the TX.
> |- Everything on a local node that know about the TX.
>
> By global I mean world, unique XID.
>
> |In the following I assume you mean the last definition,
> |since we are talking JTA and JTA defines VM-local
> |interfaces only. (And X/Open DTM and CORBA OTS has
> |no remote interface for tx suspension.)
>
> hence the emptiness of the "suspension" in specs.
Cannot be global as in "all computers", due to
lack of distributed suspension interfaces. There
is simply no way (with any TX distribution
technologies I know of) to distribute a TX
suspension (whatever that is) from one computer
to another.
So TX suspension has to be (at least) VM-local.
> |You say that suspend on the "transaction" (I read:
> |transaction associated with local thread) would
>
> no, I mean "suspend global transaction". The fact that it is associated is
> irrelevant, it is a system hack.
>
> |suspend the "global transaction" (I read: Any
> |thread local transaction representing the same global
> |transaction in the local VM) and propagate to the
> |other "local" associations.
> |But what exactly do you mean by this?
>
> I mean "suspend the transaction". If you have many objects reprensenting
> the transaction or many resources that need to be notified of this lifecycle
> event on the transaction then you propagate that since they need to be
> called back.
>
> |If you mean the thread association (I don't
> |really think so), it would mean that the tx
> |is disassociated from all threads when one of
> |them calls TM.suspend().
>
> Yes it is disassociated, just like there is disassociation on other life
> cycle events.
Thread association suspension is thread-local,
even if TM.suspend() is called to do it.
See first JTA section 3.2.3 quote below.
>
> |If you mean the resource suspension: Yes this
> |touches the entire tx, as seen from any
> |thread. But JTA says it this is the
> |responsibility of the application server (not
> |the TM) to do this.
>
> I guess the TM doesn't keep track of who is listening to the global
> transaction.
> I don't understand why JTA has anything to do with it...
It hasn't. That is the responsibility of
the application server.
See second JTA section 3.2.3 quote below.
But when a resource is suspended from a
transaction it is suspended from that tx
no matter where or how the tx is seen.
> Let me be MUCH MUCH clearer. WHY IN THE HECK DO YOU NEED TO NOTIFY A
> LISTENER THAT A PARTICULAR CONTAINER IS DONE WITH A PARTICULAR THREAD. IT
> IS NOT A TX LIFECYCLE EVENT IT IS JUST A "please disassociate this thread".
Yes.
> But if you do it with "suspend" a valid TM will actually SUSPEND the global
> TX this is not what you want you just want to tell the TM about threads.
No. I am trying to argue that the way JTA
defines TM suspend()/resume() methods is
that they *only* do local thread association.
It is just not very clearly stated, and the
method names chosen are misleading.
(My guess is that JTA simply copied the method
names and functionality from the OTS/JTS Current
interface, that does local thread association
only. OTS does not introduce an undefined term
"transaction suspend", but clearly states that
the Current methods suspend() and resume() do
thread association suspension/resumption.)
> |> |And since section 3.2.3 (about these two
> |> |methods) also says "Thread association done
> |> |here" and "Resource tx suspension is caller's
> |> |responsibility", I find it hard to read the
> |> |JTA spec any other way than "the method names
> |> |are misleading", and "these methods do (almost)
> |> |what the JBoss-specific thread association
> |> |does".
> |>
> |> hmmmm I think it is due to the fact that most people missread this (few
> |> people understand TX). To me it is pretty clear. I did factor out the
> |> "Thread association" as a portability layer in propagation context... you
> |> put them back as one, in my opinion it is misleading.
> |
> |I think that I am about to understand your point
> |here. Some kind of layer of code is needed for
> |keeping track of:
> |- Which components are executing in which TXs.
> |- Which resource connections are open, and
> | which components have them open.
> |I just cannot read JTA as saying that this
> |functionality should belong to the JTA
> |implementation.
>
> It does not and in fact I do not talk about that.
>
> yes that is needed and it is I believe somewhat covered in the JCA arch?
> (correct me if I am wrong).
I haven't studied JCA closely yet, but it looks
to me like a generalization of XAConnection.
So it specifies JTA XA resources for any backend,
not just JDBC connections.
> |If we should be independent of the actual JTA
> |implementation used we will have to do with the
> |API that JTA provides. We could have as many
>
> JTA doesn't provide an API for association and disassociation nor should it.
> That is the reason for my API for "associateThread" and "disthread", suspend
> and resume ? no.
I think you are wrong here.
Quoting JTA 1.0.1 specification, section 3.2.3:
"A call to the TransactionManager.suspend method
temporarily suspends the transaction that is
currently associated with the calling thread.
If the thread is not associated with any
transaction, a null object reference is returned;
otherwise, a valid Transaction object is returned.
The Transaction object can later be passed to the
resume method to reinstate the transaction context
association with the calling thread.
The TransactionManager.resume method re-associates
the specified transaction context with the calling
thread. If the transaction specified is a valid
transaction, the transaction context is associated
with the calling thread; otherwise, the thread is
associated with no transaction."
So thread association *is* done in these methods.
Further quoting section 3.2.3:
"The application server is responsible for ensuring
that the resources in use by the application are
properly delisted from the suspended transaction.
A resource delist operation triggers the Transaction
Manager to inform the resource manager to
disassociate the transaction from the specified
resource object (XAResource.end(TMSUSPEND)).
When the application s transaction context is
resumed, the application server ensures that the
resource in use by the application is again enlisted
with the transaction. Enlisting a resource as a
result of resuming a transaction triggers the
Transaction Manager to inform the resource manager
to re-associate the resource object with the resumed
transaction (XAResource.start(TMRESUME))."
So JTA says that resource suspension/resumption
is *not* the responsibility of the JTA
implementation when suspending/resuming with
TM.suspend()/TM.resume().
But besides thread association suspension and
resource suspension, what is in a tx suspension?
IMO nothing.
But that leaves *only* thread association
suspension/resumption to be done in the TM
suspend()/resume() methods.
> Well please answer clearly where I can associate the thread with the
> transaction (we do that quite a lot in the containers, all the time, almost
> every entity call)... ***HOW*** do you implement that call, with resume?
Well, I haven't changed any of that code, but
I would like the container to get rid of any
non-JTA calls to the TM.
J2EE-RI and JonAS use TM.resume() for this.
In both cases, the code is a little hard to
read because resource suspension/resumption
is done in the JTA impl (JonAS), or in a
layer on top of it (J2EE-RI). In neither
case there is special thread association
methods.
But if JTA TM suspend()/resume() do thread
association only as I am arguing, it would
not be that bad to use this, would it?
Best Regards,
Ole Husgaard.
