You are right, an OTS implementation is not required to support nested
transactions but it is still in the spec.
/Tommy
> -----Ursprungligt meddelande-----
> Fr�n: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]F�r Rob Castaneda
> Skickat: den 14 juni 2000 11:05
> Till: jBoss Developer
> �mne: Re: [jBoss-Dev] Transactions, please!
>
>
> >>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
>
>
>
>
