[transaction] AbstractXAResource throws exception on TMJOIN

[Joerg Heinicke <jo...@gmx.de>]

Hello,

there seems to be some inconsistency in the implementation of AbstractXAResource
regarding TMJOIN in the start() method. The first thing that is checked for in
this method is "getCurrentlyActiveTransactionalResource() != null" and a
XAException is thrown if there is a currently active transactional resource
(CATR). But IMO this is wrong for TMJOIN as you want to join a transaction, so
there must be a CATR.

>From the implementation of the start method I assume TMJOIN implementation is
included, but wrong. For joining an active transaction also
"createTransactionResource()" is called while probably
"getActiveTransactionalResource(Xid xid)" would be correct.

WDYT?

Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [transaction] AbstractXAResource throws exception on TMJOIN

[Joerg Heinicke <jo...@gmx.de>]

Oliver Zeigermann <oliver.zeigermann <at> gmail.com> writes:

> But even more, may understanding is that the user will never see an
> XAResource and will never try to get an instance of it. It simply is
> an interface between the transaction manager of your container and
> your resource manager.

Ok, this might be the reason for my different views up to now. Is an XAResource
always supposed to be accessed through JCA, i.e. the resource adapter is an
implementation of JCA? I got the impression when having again a look on your
transactional Map implementation. Unfortunately the JTA spec does not speak
about this point (JCA), only mentions JDBC and JMS, which might be an analogy
here.

Yet another spec/API I have to look at ... and maybe the JTA spec makes more
sense with this changed view.

Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [transaction] AbstractXAResource throws exception on TMJOIN

[Oliver Zeigermann <ol...@gmail.com>]

2005/11/18, Joerg Heinicke <jo...@gmx.de>:
> Oliver Zeigermann <oliver.zeigermann <at> gmail.com> writes:
>
> > Hmmm. I do not understand you either.
>
> :)
>
> > I have certainly read the XA spec, but - of course - am not entirely sure that
> > my implementation is free of errors.
>
> I did not know that it was you implementing it.

Does not matter too much who did the initial impementation...
> > Active and suspended contexts are of course shared by the XA resource,
> > why should it be local to a thread then?
>
> My problem is that the contexts are specific to an XAResource *instance*. But is
> it not possible to have more than one instance accessing one resource manager

No. I do not think so.

> from one thread? This is what my example with the two components was about. If
> you use JNDI (standard in EJB 2.x) for looking up your XAResource you get a new
> instance of XAResource for each lookup, so one for both components. This is why
> I think the contexts must be made known to the thread (hence ThreadLocal), not
> only to the instance.

Hmmm. At least I understand what you are saying now. If there were
more than one instance per thread a thread local still would not work,
as the data has to be shared by all participants of the transactions,
i.e. threads.

But even more, may understanding is that the user will never see an
XAResource and will never try to get an instance of it. It simply is
an interface between the transaction manager of your container and
your resource manager.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [transaction] AbstractXAResource throws exception on TMJOIN

[Joerg Heinicke <jo...@gmx.de>]

Oliver Zeigermann <oliver.zeigermann <at> gmail.com> writes:

> Hmmm. I do not understand you either.

:)

> I have certainly read the XA spec, but - of course - am not entirely sure that
> my implementation is free of errors.

I did not know that it was you implementing it. And about the errors: that's
what I want to find out. Interpreting the spec is not that easy IMO, it is
really database specific and talks about "connection's close" method: Huh? Is it
about JTA or JDBC? Where is a connection in JTA.

> Active and suspended contexts are of course shared by the XA resource,
> why should it be local to a thread then?

My problem is that the contexts are specific to an XAResource *instance*. But is
it not possible to have more than one instance accessing one resource manager
from one thread? This is what my example with the two components was about. If
you use JNDI (standard in EJB 2.x) for looking up your XAResource you get a new
instance of XAResource for each lookup, so one for both components. This is why
I think the contexts must be made known to the thread (hence ThreadLocal), not
only to the instance.

> Maybe the misunderstanding is the active transaction branch which is
> associated to a specific thread. That's why it is a thread local. This
> means if there is a tx associated to a thead it will be stored there.

No I think, that is clear. It is only difficult to control if you allow multiple
XAResource instances per thread - which is allowed from my understanding.

Hope it's getting clearer where my actual problem is.

Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [transaction] AbstractXAResource throws exception on TMJOIN

[Oliver Zeigermann <ol...@gmail.com>]

Hmmm. I do not understand you either. I have certainly read the XA
spec, but - of course - am not entirely sure that my implementation is
free of errors.

Active and suspended contexts are of course shared by the XA resource,
why should it be local to a thread then?

Maybe the misunderstanding is the active transaction branch which is
associated to a specific thread. That's why it is a thread local. This
means if there is a tx associated to a thead it will be stored there.

Oliver

2005/11/17, Joerg Heinicke <jo...@gmx.de>:
> Oliver Zeigermann <oliver.zeigermann <at> gmail.com> writes:
>
> > > there seems to be some inconsistency in the implementation of
> > > AbstractXAResource regarding TMJOIN in the start() method. The first thing
> > > that is checked for in this method is
> > > "getCurrentlyActiveTransactionalResource() != null" and a XAException is
> > > thrown if there is a currently active transactional resource (CATR). But IMO
> > > this is wrong for TMJOIN as you want to join a transaction, so
> > > there must be a CATR.
> >
> > A thread can only be part of at most one transaction at a time. If it
> > already has an active transaction, joining another is an invalid
> > operation.
>
> Sorry, but I don't understand you here. If a thread can only have one
> transaction, why is it not allowed to join this active one?
>
> But re-reading the spec I came to the conclusion that the "CATR != null" check
> is not the problem. In section 3.4.4 of the spec (you know it?) there is a table
> about the correct XAResource to transaction association. And for both
> start(NOFLAGS) and start(TMJOIN) the XAResource can only switch from "not
> associated" to "associated" meaning that the null check is ok.
>
> But as far as I understand the spec there can be multiple instances of
> XAResource accessing the same resource manager (otherwise TMJOIN makes no sense,
> and XAResource.isSameRM(XAResource) neither).
> Example: Both component1 and component2 have a method requiring a transaction,
> and component1 calls component2. Both lookup the same XAResource from JNDI
> actually getting different instances of this XAResource. When component2 now
> accesses the XAResource it actually *joins* the transaction.
>
> This means that another aspect of AbstractXAResource is wrong: I already
> mentioned createTransactionResource(Xid) for TMJOIN in the last mail. IMO it
> must be getActiveTransactionalResource(Xid). This leads to another change to get
> it working as the activeContexts would be empty of course: The both maps
> suspendedContexts and activeContexts must be static ThreadLocal variables.
>
> Regards,
>
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [transaction] AbstractXAResource throws exception on TMJOIN

[Joerg Heinicke <jo...@gmx.de>]

Oliver Zeigermann <oliver.zeigermann <at> gmail.com> writes:

> > there seems to be some inconsistency in the implementation of
> > AbstractXAResource regarding TMJOIN in the start() method. The first thing
> > that is checked for in this method is
> > "getCurrentlyActiveTransactionalResource() != null" and a XAException is
> > thrown if there is a currently active transactional resource (CATR). But IMO 
> > this is wrong for TMJOIN as you want to join a transaction, so
> > there must be a CATR.
> 
> A thread can only be part of at most one transaction at a time. If it
> already has an active transaction, joining another is an invalid
> operation.

Sorry, but I don't understand you here. If a thread can only have one
transaction, why is it not allowed to join this active one?

But re-reading the spec I came to the conclusion that the "CATR != null" check
is not the problem. In section 3.4.4 of the spec (you know it?) there is a table
about the correct XAResource to transaction association. And for both
start(NOFLAGS) and start(TMJOIN) the XAResource can only switch from "not
associated" to "associated" meaning that the null check is ok.

But as far as I understand the spec there can be multiple instances of
XAResource accessing the same resource manager (otherwise TMJOIN makes no sense,
and XAResource.isSameRM(XAResource) neither).
Example: Both component1 and component2 have a method requiring a transaction,
and component1 calls component2. Both lookup the same XAResource from JNDI
actually getting different instances of this XAResource. When component2 now
accesses the XAResource it actually *joins* the transaction.

This means that another aspect of AbstractXAResource is wrong: I already
mentioned createTransactionResource(Xid) for TMJOIN in the last mail. IMO it
must be getActiveTransactionalResource(Xid). This leads to another change to get
it working as the activeContexts would be empty of course: The both maps
suspendedContexts and activeContexts must be static ThreadLocal variables.

Regards,

Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [transaction] AbstractXAResource throws exception on TMJOIN

[Oliver Zeigermann <ol...@gmail.com>]

2005/11/17, Joerg Heinicke <jo...@gmx.de>:
> there seems to be some inconsistency in the implementation of AbstractXAResource
> regarding TMJOIN in the start() method. The first thing that is checked for in
> this method is "getCurrentlyActiveTransactionalResource() != null" and a
> XAException is thrown if there is a currently active transactional resource
> (CATR). But IMO this is wrong for TMJOIN as you want to join a transaction, so
> there must be a CATR.

A thread can only be part of at most one transaction at a time. If it
already has an active transaction, joining another is an invalid
operation.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org