just adressing the 'subgroup' point. Yes, the TM is a biggy. I am not
really happy with the prospect future of the JOnAS TxMan. The todo for
"project Game Over" will be done over the next few days with the board.
We will try to post a todo PGO by next monday, earlier if we can
marc
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg
> Sent: Tuesday, June 13, 2000 1:49 AM
> To: jBoss Developer
> Subject: 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).
>
> 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?)
>
> > 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).
>
> /Rickard
>
> --
> Rickard �berg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> http://www.telkel.com
> http://www.jboss.org
> http://www.dreambean.com
>
>
