WARNING this message is only for the brave :)
I've looked into Tyrex source more closely
First Tyrex decides if the transaction can be committed in 1 phase
(i.e. optimized commit) if not, it goes into 2pc.
In 2pc it does the following:
It calls prepare() method which does a bunch of things
1. calls subordinate OTS resources to prepare and gets their votes,
counting the commit votes and setting up a decision for the
future on what to do (Tyrex calls it a heuristic). Initially the
heuristic is READONLY but as OTS resources and XA resource are
prepared this heuristic may change to ROLLBACK, MIXED, HAZARD,
etc.
2. ends all the enlisted XA resources and calls prepare() on them and then
on all the delisted XA resources as well
3. if all went well the transaction now is set to PREPARED state and it's
current heuristic is evaluated
the interesting case is here, even if the current heuristic is
READONLY, but if you have 1 or more resource requiring a commit
(remember, we've been counting those during prepare() on OTS and
XA resources) the heuristic is set to COMMITTING
4. After all that, Tyrex evaluates what to do based on the current
heuristic state. If it is READONLY, the transaction is really committed
but if it is COMMITTING, Tyrex calls commit() on all the resources that
require committing and then __!!!!__ calls forget on all of them.
I have skipped a lot of error checking Tyrex does and the exceptions it
throws at various points, the logic listed above is what goes on when my
scenario is deployed
In my scenario the originator tx has 2 subordinate transactions which are
registered with the originator as OTS resources. When originator tx is
asked to commit, Tyrex goes through the above sequence
1. prepares the subordinate transactions
- the subordinate transactions prepare their XA
resources (minerva) and return their votes, in my case: VoteCommit
- the originator now has 2 resources that voted to commit
2. having no XA resources in the originator we skip the preparation of
XA resources of the originator
3. now the originator makes a decision to commit because 2 of the
resources voted to commit and none otherwise
4. the originator calls internalCommit() which calls commit() on all the
resources that voted to commit in prepare() phase
- this propagates the commit() to the subordinate transactions,
those in turn call commit() on their XA resources
5. the originator calls forget() on all resources
- this propagates the forget() to the subordinate transactions and
their XA resources which causes an exception in Minerva because
forget() is not allowed after a commit()
Well, while I was going through all this stuff, I've decided to go back
and look for documentation and realized I had it all along -- the ots
spec, to which Tyrex conforms.
It seems this is indeed another Tyrex bug.. sigh :(
OTS spec says
10.2.6
HeuristicExceptions
A heuristic decision is a unilateral decision made by one or more
participants in a transaction to commit or rollback updates without first
obtaining the consensus outcome determined by the Transaction Service.
Heuristic decisions are normally made only in unusual circumstances, such
as communication failures, that prevent normal processing. When a
heuristic decision is taken, there is a risk that the decision will differ
from the consensus outcome, resulting in a loss of data integrity.
10.5.1
Normal Transaction Completion
Coordinator Role
page 10-51
- The root coordinator issues forget to a resource after it receives a
heuristic exception.
In my scenario there are no exceptions, forget() should not get called...
I'll get in touch with the Tyrex developers tomorrow.
Thanks to everybody for their help in this.
-------------------------------------------------------------------------
Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical
Sciences, NYU 719 Broadway, #715 Tel: 212 998-3525 New York, NY 10003 Fax:
212 995-4123
-------------------------------------------------------------------------
On Thu, 31 May 2001, David Jencks wrote:
> Hi,
> Thanks for correcting your terminology to prepare, commit.
>
> I am not a total expert but I'm pretty sure of this.
>
> I think there is still a problem either with terminology or tyrex.
>
> Heuristics are used _only_ when the transaction manager loses contact with
> one of the parties to a multi-resource transaction after prepare starts and
> before commit finishes. I don't understand all the rules but basically if
> noone has committed ( all prepared or open) then you can roll back. If one
> party has committed you have to commit every party you can: all parties
> must have voted for commit.
>
> There is also a partial 1 phase optimization possible, which I think is
> what you are describing Tyrex as using: the tm can call prepare on all but
> one of the resources: if they all vote ok, it can call 1 phase commit on
> the last: if it succeeds, commit all the others, if it fails, rollback all
> the others.
>
> I see the javadoc for forget says:
>
> Tell the resource manager to forget about a heuristically completed
> transaction branch.
>
> I think based on this that tyrex has no business calling forget unless some
> error occurs and it actually uses heuristics to complete some transaction
> branches. It is difficult to tell, I agree, since the jta spec seems to
> raise vagueness to new heights. We may need to track down the cae x/open
> xa spec from 1992 to try to understand more.
>
> My impression, which I have no solid evidence for, is that the use of
> forget was on transactions retrieved from limbo (prepared but not
> committed) by recover.
>
> david jencks
>
> On 2001.05.31 16:32:56 -0400 Anatoly Akkerman wrote:
> >
> > > > The subordinate transactions (on server2 and server3) call commit()
> > on
> > > > their datasources and return their votes to the main coordinator. The
> > > > coordinator based on the votes takes a heuristic decision on what to
> > do
> > > > about the completion of this transaction. If there were no errors
> > > > reported, the TM decides to complete the commit heuristically. So, it
> > does
> > > > not throw any exceptions, but tries to tell all the subordinates to
> > > > forget() the transaction. This indicated that the last request
> > (commit())
> > > > was accepted by everybody and everybody can now forget about this
> > > > transaction.
> > >
> > > I don't see how this can work. What happens if one of the
> > subtransactions
> > > fails? I would have thought that the originator would need to use some
> > > kind of two-phase protocol to make sure that all of the subtransactions
> > > are prepared successfully before asking any of them to commit.
> >
> > My mistake, of course it calles prepare() and gets the votes then calls
> > the commit() and makes a heuristic decision on whether to finish off with
> > forget() or to rollback() and then forget(). I am not currently looking
> > at
> > the Tyrex source and I am not a transaction specialist myself, so I don't
> > remember all the details off hand.
> >
> > Sorry for skipping the prepare() phase. Tyrex is fully standard
> > compliant. The 2pc commit happens as it supposed. The problem arises with
> > the XAResource not expecting the forget() after a successful
> > commit() on the minerva resource.
> >
> >
> > > > I can't forget something I did not really know :)
> > > > Again, I am quite new to this stuff.
> > >
> > > As am I. Have you contacted the Tyrex people about this?
> >
> > I don't think it is a Tyrex issue. I'll probably get in touch with them,
> > though. We have cleared a few other bugs in Tyrex while I was working on
> > the integration. Maybe they have something to say about this, after all
> > they've recommended minerva on their mailing list as far as I can
> > remember.
> >
> > >
> > > Toby.
> > >
> >
> > Anatoly.
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
