>>OTS is big and much of it isn't required in a J2EE impl, e.g.
>>subtransactions, still... ;-)
I thought that nested transactions were an 'optional' feature in OTS, given
that not many implement it
-Rob
----- Original Message -----
From: Tommy Hellstr�m <[EMAIL PROTECTED]>
To: jBoss Developer <[EMAIL PROTECTED]>
Sent: Tuesday, June 13, 2000 8:38 PM
Subject: Re: [jBoss-Dev] Transactions, please!
Hi!
> -----Ursprungligt meddelande-----
> Fr�n: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]F�r Rickard �berg
> Skickat: den 13 juni 2000 10:49
> Till: jBoss Developer
> �mne: Re: SV: [jBoss-Dev] Transactions, please!
>
>
> Hi!
>
> Tommy Hellstr�m wrote:
> > > > > > and
> > > > > > the large amount of possible failures that can happen,
> > > > >
> > > > > All of which are reported to the TM as an exception.
> > > >
> > > > I don't think that is the case. Consider the case when we have
> > > subordinate coordinator as
> > > > a participant in a transaction that dies after sending PREPARED
> > > to the coordinating TM.
> > > > When the participating does its recovery it see that COMMITED
> > > is not logged so it has no
> > > > way of telling if the coordinator has sent COMMIT or not, it
> > > then has to run a
> > > > termination protocol of some kind. Right?
> > >
> > > Hm.. I thought that only the top TM was allowed to do
> commits... I need
> > > to read up perhaps.. you might be right.
> >
> > You are right, only the top TM can do commits. Let me try to explain the
> > example above better.
> >
> > You have a transaction with a top TM that has one subcoordinator, called
> > sub-TM. Let us see how the top-TM and the sub-TM handles a
> COMMIT. Assume
> > presumed rollback as well.
> >
> > top-TM ("Simplified normal procedure")
> > --------------------------------------
> > 1. Sends a PREPARE request to all of its participant
> > 2. Gets PREPARED responses from all of its participants
> > 3. Sends a COMMIT request to all of its participants. A log
> record about the
> > commit and a list of all participants is written.
> >
> > sub-TM ("Simplified normal procedure")
> > --------------------------------------
> > 1. Gets a PREPARE request from the top-TM.
> > 2. Relays the PREPARE request to all of its participants
> > 3. Gets PREPARED responses from all of its participants
> > 4. Returns PREPARED response to the top-TM. A log about the
> PREPARED state,
> > a reference to the top-TM and a list of its participant as to
> be written.
> > 5. Gets a COMMIT request from the top-TM
> > 6. Relay to participants.
> > 7. Get responses from participants
> > 8. Respond to top-TM
> >
> > What complicates the example above is possible failures, and
> failures alone.
> > For example, when the sub-TM dies between step 4 and 5 above,
> (which is what
> > I tried to explain in the earlier mail.) the sub-TM has no way
> of knowing if
> > the top-TM has issued a COMMIT or not so it has to run a termination
> > protocol to figure that out.
>
> I think that if the sub-TM is added as a XAResource to the top-TM this
> will work out by way of recursion. First of all, if the sub-TM dies,
> then the top-TM *have to* rollback (by using .forget calls to all
> XAResources).
I don't think that is the case cause the top-TM can send out COMMIT to other
participant before it gets an exception from the failing sub-TM. I think
forget() should be used to notify a resource, that earlier has made a
heuristic decision and after that thrown a heuristic exception, to forget
about it.
>
> We should probably open up a subproject of jBoss for the TM which should
> include more people than just me. It would be better if I did not make
> this kinds of decision in a dictatorial way, both for technical and
> community reasons.
>
> This will be part of the general upgrade of the jBoss community
> management. We will open up a list of subprojects which people will be
> able to join. This will be an important part of that. (Marc, any
> news/ideas on this?)
That would be great and I think it is a really good idea!
>
> > To summarize: The recovery process a TM has to make during
> start-up is much
> > more complicated when we have sub-TMs. OTS has all that
> covered. OTS uses
> > IIOP as a protocol but I don't see why it couldn't be any
> transport. If you
> > aren't a transaction expert (like me, I mean that I'm not an
> expert...) it
> > can really be better to follow a standard document than trying
> to figuring
> > out what to do by yourself.
>
> Yes, I agree, but OTOH I think OTS is overkill. But that's just my
> opinion, and I definitely acknowledge that there are others (equally
> valid depending on your viewpoint).
OTS is big and much of it isn't required in a J2EE impl, e.g.
subtransactions, still... ;-)
Regards,
/Tommy
