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
