Issue 4343: interposed coordinator optimisation (ots-rtf) Source: Red Hat (Dr. Mark Little, mlittle(at)redhat.com) Nature: Uncategorized Issue Severity: Summary: When using interposition it's possible for (and I'd argue it probably should) a subordinate coordinator to run the two-phase commit protocol on its registered resources (almost) independently of the root coordinator (or the coordinator it's registered with). Say the subordinate coordinator gets a prepare message which it then sends to its locally registered resources, if one of them returns VoteRollback then the subordinate knows that it will eventually have to rollback all registered resources. Now it could simply do nothing more and send VoteRollback up the tree, knowing that it will eventually get a rollback call to then distributed on to its registered resources. Alternatively, it could send rollback to all of its resource before sending the VoteRollback up the tree (and then it could obviously go). Although we shouldn't mandate an implementation, it might be useful to mention the above optimisation in the text. Perhaps during the Implementor's View. Resolution: close issue, see above Revised Text: Actions taken: June 13, 2001: received issue May 13, 2002: closed issue Discussion: Close this issue as it is mentioned in the section on subordinate coordinator on page 10-58. End of Annotations:===== From: "Mark Little" To: "OTS RTF" Subject: interposed coordinator optimisation Date: Wed, 6 Jun 2001 20:00:10 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Filter-Version: 2.1 (cheviot3) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: %(Rd9QNR!!01K!!Q:Oe9 When using interposition it's possible for (and I'd argue it probably should) a subordinate coordinator to run the two-phase commit protocol on its registered resources (almost) independently of the root coordinator (or the coordinator it's registered with). Say the subordinate coordinator gets a prepare message which it then sends to its locally registered resources, if one of them returns VoteRollback then the subordinate knows that it will eventually have to rollback all registered resources. Now it could simply do nothing more and send VoteRollback up the tree, knowing that it will eventually get a rollback call to then distributed on to its registered resources. Alternatively, it could send rollback to all of its resource before sending the VoteRollback up the tree (and then it could obviously go). Although we shouldn't mandate an implementation, it might be useful to mention the above optimisation in the text. Perhaps during the Implementor's View. Mark. ---------------------------------------------- Dr. Mark Little (mark@arjuna.com) Transactions Architect, HP Arjuna Labs Phone +44 191 2064538 Fax +44 191 2064203 From: "Gary Tully" To: "Mark Little" , "OTS RTF" Subject: RE: interposed coordinator optimisation Date: Wed, 13 Jun 2001 15:04:38 +0100 Message-ID: <000401c0f411$c887d3a0$2201020a@dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Importance: Normal In-Reply-To: <002201c0f3fe$c26efbf0$9901f080@thinkblue> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: fC~e90@"e9HC]!!~@M!! Hi Mark, this must always be the case because there is no requirement on the coordinator to send a rollback to a resource once it returns a vote rollback to a prepare. see:10-32 CORBAservices July 19, 2000 - top of page: The resource can return VoteRollback under any circumstances, including not having any knowledge about the transaction (which might happen after a crash). If this response is returned, the transaction must be rolled back. Furthermore, the Transaction Service is not required to perform any additional operations on this resource. After returning this response, the resource can forget all knowledge of the transaction. > -----Original Message----- > From: Mark Little [mailto:mcl@arjuna.com] > Sent: Wednesday, June 06, 2001 8:00 PM > To: OTS RTF > Subject: interposed coordinator optimisation > > > When using interposition it's possible for (and I'd argue it probably > should) a subordinate coordinator to run the two-phase commit protocol on > its registered resources (almost) independently of the root > coordinator (or > the coordinator it's registered with). Say the subordinate > coordinator gets > a prepare message which it then sends to its locally registered resources, > if one of them returns VoteRollback then the subordinate knows > that it will > eventually have to rollback all registered resources. Now it > could simply do > nothing more and send VoteRollback up the tree, knowing that it will > eventually get a rollback call to then distributed on to its registered > resources. Alternatively, it could send rollback to all of its resource > before sending the VoteRollback up the tree (and then it could obviously > go). > > Although we shouldn't mandate an implementation, it might be useful to > mention the above optimisation in the text. Perhaps during the > Implementor's > View. > > Mark. > > ---------------------------------------------- > Dr. Mark Little (mark@arjuna.com) > Transactions Architect, HP Arjuna Labs > Phone +44 191 2064538 > Fax +44 191 2064203 > > > From: "Mark Little" To: "Gary Tully" , "OTS RTF" References: <000401c0f411$c887d3a0$2201020a@dublin.iona.ie> Subject: Re: interposed coordinator optimisation Date: Wed, 13 Jun 2001 15:32:12 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Filter-Version: 2.1 (cheviot3) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: hWnd94%~!!]^g!!g_Sd9 > this must always be the case because there is no requirement on the > coordinator to send a rollback to a resource once it returns a > vote rollback to a prepare. > > see:10-32 CORBAservices July 19, 2000 - top of page: > The resource can return VoteRollback under any circumstances, > including not > having > any knowledge about the transaction (which might happen after a > crash). If > this > response is returned, the transaction must be rolled > back. Furthermore, the > Transaction > Service is not required to perform any additional operations on this > resource. After > returning this response, the resource can forget all knowledge of > the > transaction. Agreed, but I'm not talking about a pure Resource. As I said in the original email, I'm talking about an interposed coordinator. From the root coordinator (or whatever it's ancestor coordinator may be) it looks like a Resource, but from its participants p.o.v. it's a coordinator. When the ancestor coordinator sends prepare and the interposed coordinator sends VoteRollback it need not have actually sent rollback to its participants - it may only have finished prepare and then sent the response - it would be a compliant implementation. Certainly the OTS specification could be read as implying it can do a rollback before sending the response (though it does take a little jump to get from the text quoted to what I believe most implementations of interposition do), but after talking to Eric Newcomer last week I'd like to have this as an example in the text. Mark. ---------------------------------------------- Dr. Mark Little (mark@arjuna.com) Transactions Architect, HP Arjuna Labs Phone +44 191 2064538 Fax +44 191 2064203 Date: Sun, 24 Jun 2001 13:17:18 +0200 From: simone sedillot Organization: inria X-Mailer: Mozilla 4.5 [fr] (WinNT; I) X-Accept-Language: fr MIME-Version: 1.0 To: Juergen Boldt CC: issues@emerald.omg.org, ots-rtf@emerald.omg.org Subject: Re: issue 4343 -- OTS issue References: <4.3.2.7.2.20010613112243.00b4ab30@emerald.omg.org> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: $b_!!^7hd9SB;e9T?3e9 as the ISO OSI TP protocol state table editor, that is really old time, i cannot but resist anr rejot that at last this optimisation comes, which is the normal way in OSI TP and our INRIA implementation for performance reason. To go further, the interposed coordinator superior in the tree , when it receives a vote-rollback on its prepare , could rollback its registered resources. Simple and early resource locking release. Probably the OTS approach was due to some vendor implementation. best regards to all simone Juergen Boldt a crit : > This is issue # 4343 "Mark Little" > > interposed coordinator optimisation > > When using interposition it's possible for (and I'd argue it >probably > should) a subordinate coordinator to run the two-phase commit >protocol on > its registered resources (almost) independently of the root >coordinator (or > the coordinator it's registered with). Say the subordinate >coordinator gets > a prepare message which it then sends to its locally registered >resources, > if one of them returns VoteRollback then the subordinate knows that >it will > eventually have to rollback all registered resources. Now it could >simply do > nothing more and send VoteRollback up the tree, knowing that it will > eventually get a rollback call to then distributed on to its >registered > resources. Alternatively, it could send rollback to all of its >resource > before sending the VoteRollback up the tree (and then it could >obviously > go). > > Although we shouldn't mandate an implementation, it might be useful >to > mention the above optimisation in the text. Perhaps during the >Implementor's > View. > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > URL: www.omg.org > > ================================================================ Reply-To: From: "Eric Newcomer" To: "Mark Little" , "Gary Tully" , "OTS RTF" Subject: RE: interposed coordinator optimisation Date: Sun, 24 Jun 2001 15:33:57 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <019a01c0f415$a3888e60$9901f080@thinkblue> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Sj]d9/_Ud9#=(!!`cDe9 I agree that most implementations will want to do this for the sake of effeciency. I also agree it's not something we can mandate in the spec, but it would be good to have a hint or suggestion in the Implementor's View. The point is that once a rollback is signaled from anywhere in tree, no result but rollback is possible from that point onward, and the resources might as well be notified immediately so they can release context before or at the same time as the interposed coordinator(s) notify the parent(s). Thanks, Eric -----Original Message----- From: Mark Little [mailto:mcl@arjuna.com] Sent: Wednesday, June 13, 2001 10:32 AM To: Gary Tully; OTS RTF Subject: Re: interposed coordinator optimisation > this must always be the case because there is no requirement on the > coordinator to send a rollback to a resource once it returns a > vote rollback to a prepare. > > see:10-32 CORBAservices July 19, 2000 - top of page: > The resource can return VoteRollback under any circumstances, > including not > having > any knowledge about the transaction (which might happen after a > crash). If > this > response is returned, the transaction must be rolled > back. Furthermore, the > Transaction > Service is not required to perform any additional operations on this > resource. After > returning this response, the resource can forget all knowledge of > the > transaction. Agreed, but I'm not talking about a pure Resource. As I said in the original email, I'm talking about an interposed coordinator. From the root coordinator (or whatever it's ancestor coordinator may be) it looks like a Resource, but from its participants p.o.v. it's a coordinator. When the ancestor coordinator sends prepare and the interposed coordinator sends VoteRollback it need not have actually sent rollback to its participants - it may only have finished prepare and then sent the response - it would be a compliant implementation. Certainly the OTS specification could be read as implying it can do a rollback before sending the response (though it does take a little jump to get from the text quoted to what I believe most implementations of interposition do), but after talking to Eric Newcomer last week I'd like to have this as an example in the text. Mark. ---------------------------------------------- Dr. Mark Little (mark@arjuna.com) Transactions Architect, HP Arjuna Labs Phone +44 191 2064538 Fax +44 191 2064203 From: "Mark Little" To: "Bernard Normier" , "OTS RTF" References: <03d001c19d50$ae1faae0$4985413f@boston.amer.iona.com> Subject: Re: Let's solve some OTS issues! Date: Wed, 16 Jan 2002 17:51:14 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ee"e9GF#!!=*~e9<0)!! A few proposals to issues I've raised in the past then: Issue 1929: the timeout value sent in transaction contexts for top-level transactions is the time remaining (in seconds). Issue 1848: update the description of register_synchronization to require SynchronizationUnavailable to be thrown if the current transaction is a subtransaction. Issue 2618: modify the paragraph on register_resource to include: "If a the resource is a Resource and the current transaction is a subtransaction, then the Resource is registered as a participant in the current transaction and indirectly with the parent if the current transaction commits and all parents up to the root transaction also commit." Issue 4343: close this issue as it is mentioned in the section on subordinate coordinator on page 10-58. I'd like to address a couple of older issues (1998) about subtransactions but this will require a revisit about what we think subtransactions are! A little late for what could be a long discussion. BTW, have we removed anonymous types from the IDL as 3762 mentions? Mark. ---------------------------------------------- Dr. Mark Little, Distinguished Engineer, Transactions Architect, HP Arjuna Labs Email: mark_little@hp.com Phone: +44 191 2606216 Fax : +44 191 2606250