Issue 3365: OTS issue: explicit transaction propagation not clearly specified (ots-rtf) Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com) Nature: Uncategorized Issue Severity: Summary: There has now been some discussion on this subject, therefore I would like to have it registered as an official issue: issue: ------ It is not clearly specified how the implicit transaction context associated with a thread is propagated to another execution environment (at the ORB level) in case of explicit transaction propagation control. It should be clarified in various places, for example, that the PropagationContxt is not required to be transferred in case of explicit transaction propagation. dicussion: ---------- First, note the following two important aspects to transaction propagation: 1. Transaction Propagation Control: How is it controlled at the application level whether a transaction is propagated? -> the spec specifies implicit and explicit propagation control. 2. Transaction Context Propagation: How is the implicit transaction context propagated to another execution environement at the ORB level? -> implicit transfer of the PropagationContext versus explicit transfer of a Control objref (as an explicit request parameter). In principle, the spec could mandate that the PropagationContext is always transfered even when explicit transaction propagation control is used. Historically this was never intendend (see quoted message below). However, there are a lot of places where the spec speaks about implicit transfer of the PropagationContext without referring to implicit propagation control (Maybe because explicit propagation control was added at a later stage?): p. 10-60, "When the implicit context is transferred, it is represented as a PropagationContext." -> The historical intent is that in case of explicit propagation control, the implicit transaction context is transferred by passing the Control objref as an explicit request parameter. (Note that the implicit in 'implicit context' is referring to the fact that the OTS maintains implicitly transaction information with threads, its not referring to transferral. Also note that the 'implicit context' is referring to the transaction context, not the progagation context.) p. 10-60, "When the Control object is passed as an operation argument (explicit propagation), no special transfer mechanism is required." -> This could be interpreted (wrongly according to the historical intent) that no special transfer mechanism is required, implicit transferral of the PropagationContext is just fine. p. 10-61, "An interposed coordinator registers as a participant in the transaction with the Coordinator identified in the PropagationContext of the received request." -> but with explicit propagation it is not required that the received request contains a PropagationContext... p. 10-63, "When exporting a transaction, the ORB sets the PropagationContext into the ServiceContext::context_data field..." -> but this should only be required for implicit propagation control... p. 10-67, "The ORB will invoke the sender callbacks only when a transactional operation is issued for an object in a different process." -> What's the definition of a transactional operation? An operation on a transactional object? If yes, then this saying even in case of transactional objects that don't inherit TransactionalObject (ie. explicit propagation control), the ORB required to get the PropagationContext by using Sender::sending_request and to pass a PropagationContext to Sender::received_reply. ... Possible resolution: -------------------- Several people have already suggested that explicit propagation is axed from the OTS. Resolution: Revised Text: Actions taken: February 28, 2000: received issue Discussion: End of Annotations:===== Date: Wed, 1 Nov 2000 12:19:07 -0800 From: Blake Biesecker To: ots-rtf@omg.org Subject: Re: issue 3365 -- OTS RTF issue Message-ID: <20001101121907.I22222@gemstone.com> References: <4.1.20000322154042.03f2c7f0@emerald.omg.org> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <4.1.20000322154042.03f2c7f0@emerald.omg.org>; from juergen@omg.org on Wed, Mar 22, 2000 at 03:41:11PM -0500 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: X?,e9P'Td9!)>e9Y!H!! During the discussion on this issue the idea of explicit transaction propagation be dropped. Is there support for this idea? Blake On Wed, Mar 22, 2000 at 03:41:11PM -0500, Juergen Boldt wrote: > This is issue # 3365 > > OTS issue: explicit transaction propagation not clearly specified > > There has now been some discussion on this subject, therefore I would like to > have it registered as an official issue: > > issue: > ------ > It is not clearly specified how the implicit transaction context associated > with a thread is propagated to another execution environment (at the ORB > level) > in case of explicit transaction propagation control. It should be clarified in > various places, for example, that the PropagationContxt is not required to be > transferred in case of explicit transaction propagation. > > > dicussion: > ---------- > First, note the following two important aspects to transaction propagation: > > 1. Transaction Propagation Control: > How is it controlled at the application level whether a transaction is > propagated? -> the spec specifies implicit and explicit propagation control. > > 2. Transaction Context Propagation: > How is the implicit transaction context propagated to another execution > environement at the ORB level? -> implicit transfer of the PropagationContext > versus explicit transfer of a Control objref (as an explicit request > parameter). > > In principle, the spec could mandate that the PropagationContext is always > transfered even when explicit transaction propagation control is used. > Historically this was never intendend (see quoted message below). However, > there are a lot of places where the spec speaks about implicit transfer of the > PropagationContext without referring to implicit propagation control (Maybe > because explicit propagation control was added at a later stage?): > > p. 10-60, "When the implicit context is transferred, it is represented as a > PropagationContext." > -> The historical intent is that in case of explicit propagation control, the > implicit transaction context is transferred by passing the Control objref > as an > explicit request parameter. (Note that the implicit in 'implicit context' is > referring to the fact that the OTS maintains implicitly transaction > information > with threads, its not referring to transferral. Also note that the 'implicit > context' is referring to the transaction context, not the progagation context.) > > p. 10-60, "When the Control object is passed as an operation argument > (explicit > propagation), no special transfer mechanism is required." > -> This could be interpreted (wrongly according to the historical intent) that > no special transfer mechanism is required, implicit transferral of the > PropagationContext is just fine. > > p. 10-61, "An interposed coordinator registers as a participant in the > transaction with the Coordinator identified in the PropagationContext of the > received request." > -> but with explicit propagation it is not required that the received request > contains a PropagationContext... > > p. 10-63, "When exporting a transaction, the ORB sets the PropagationContext > into the ServiceContext::context_data field..." > -> but this should only be required for implicit propagation control... > > p. 10-67, "The ORB will invoke the sender callbacks only when a transactional > operation is issued for an object in a different process." > -> What's the definition of a transactional operation? An operation on a > transactional object? If yes, then this saying even in case of transactional > objects that don't inherit TransactionalObject (ie. explicit propagation > control), the ORB required to get the PropagationContext by using > Sender::sending_request and to pass a PropagationContext to > Sender::received_reply. > > > ... > > Possible resolution: > -------------------- > Several people have already suggested that explicit propagation is axed from > the OTS. > > ================================================================ > > 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 > > > > ================================================================ X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 01 Nov 2000 15:49:51 -0800 To: Blake Biesecker , ots-rtf@omg.org From: Edward Cobb Subject: Re: issue 3365 -- OTS RTF issue In-Reply-To: <20001101121907.I22222@gemstone.com> References: <4.1.20000322154042.03f2c7f0@emerald.omg.org> <4.1.20000322154042.03f2c7f0@emerald.omg.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: eEad9A5id9l60!!lXcd9 I've never been convinced it could be made to work, but it might be a bit much for an RTF. At 12:19 PM 11/1/00 -0800, Blake Biesecker wrote: >During the discussion on this issue the idea of explicit >transaction propagation be dropped. Is there support >for this idea? > >Blake > >On Wed, Mar 22, 2000 at 03:41:11PM -0500, Juergen Boldt wrote: >> This is issue # 3365 >> >> OTS issue: explicit transaction propagation not clearly specified >> >> There has now been some discussion on this subject, therefore I would like to >> have it registered as an official issue: >> >> issue: >> ------ >> It is not clearly specified how the implicit transaction context associated >> with a thread is propagated to another execution environment (at the ORB >> level) >> in case of explicit transaction propagation control. It should be clarified in >> various places, for example, that the PropagationContxt is not required to be >> transferred in case of explicit transaction propagation. >> >> >> dicussion: >> ---------- >> First, note the following two important aspects to transaction propagation: >> >> 1. Transaction Propagation Control: >> How is it controlled at the application level whether a transaction is >> propagated? -> the spec specifies implicit and explicit propagation control. >> >> 2. Transaction Context Propagation: >> How is the implicit transaction context propagated to another execution >> environement at the ORB level? -> implicit transfer of the PropagationContext >> versus explicit transfer of a Control objref (as an explicit request >> parameter). >> >> In principle, the spec could mandate that the PropagationContext is always >> transfered even when explicit transaction propagation control is used. >> Historically this was never intendend (see quoted message below). However, >> there are a lot of places where the spec speaks about implicit transfer of the >> PropagationContext without referring to implicit propagation control (Maybe >> because explicit propagation control was added at a later stage?): >> >> p. 10-60, "When the implicit context is transferred, it is represented as a >> PropagationContext." >> -> The historical intent is that in case of explicit propagation control, the >> implicit transaction context is transferred by passing the Control objref >> as an >> explicit request parameter. (Note that the implicit in 'implicit context' is >> referring to the fact that the OTS maintains implicitly transaction >> information >> with threads, its not referring to transferral. Also note that the 'implicit >> context' is referring to the transaction context, not the progagation context.) >> >> p. 10-60, "When the Control object is passed as an operation argument >> (explicit >> propagation), no special transfer mechanism is required." >> -> This could be interpreted (wrongly according to the historical intent) that >> no special transfer mechanism is required, implicit transferral of the >> PropagationContext is just fine. >> >> p. 10-61, "An interposed coordinator registers as a participant in the >> transaction with the Coordinator identified in the PropagationContext of the >> received request." >> -> but with explicit propagation it is not required that the received request >> contains a PropagationContext... >> >> p. 10-63, "When exporting a transaction, the ORB sets the PropagationContext >> into the ServiceContext::context_data field..." >> -> but this should only be required for implicit propagation control... >> >> p. 10-67, "The ORB will invoke the sender callbacks only when a transactional >> operation is issued for an object in a different process." >> -> What's the definition of a transactional operation? An operation on a >> transactional object? If yes, then this saying even in case of transactional >> objects that don't inherit TransactionalObject (ie. explicit propagation >> control), the ORB required to get the PropagationContext by using >> Sender::sending_request and to pass a PropagationContext to >> Sender::received_reply. >> >> >> ... >> >> Possible resolution: >> -------------------- >> Several people have already suggested that explicit propagation is axed from >> the OTS. >> >> ================================================================ >> >> 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 >> >> >> >> ================================================================ > > ************************************************************** Ed Cobb, Vice President, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 E-mail: ed.cobb@bea.com ************************************************************** Reply-To: From: "Eric Newcomer" To: "Edward Cobb" , "Blake Biesecker" , Subject: RE: issue 3365 -- OTS RTF issue Date: Thu, 2 Nov 2000 17:10:39 -0500 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <3.0.5.32.20001101154951.0098c3c0@svlhome2.beasys.com> Content-Type: text/plain; charset="us-ascii" X-UIDL: =+\!!AIld9Mgf!!1epd9 Wasn't there some discussion about the possibility of dropping explicit propagation altogether being easier than fixing it? Eric Newcomer IONA Technologies 200 West Street Waltham, MA 02451 Tel: +1 781 902 8366 Fax: +1 781 902 8001 -----Original Message----- From: Edward Cobb [mailto:ed.cobb@bea.com] Sent: Wednesday, November 01, 2000 6:50 PM To: Blake Biesecker; ots-rtf@omg.org Subject: Re: issue 3365 -- OTS RTF issue I've never been convinced it could be made to work, but it might be a bit much for an RTF. At 12:19 PM 11/1/00 -0800, Blake Biesecker wrote: >During the discussion on this issue the idea of explicit >transaction propagation be dropped. Is there support >for this idea? > >Blake > >On Wed, Mar 22, 2000 at 03:41:11PM -0500, Juergen Boldt wrote: >> This is issue # 3365 >> >> OTS issue: explicit transaction propagation not clearly specified >> >> There has now been some discussion on this subject, therefore I would like to >> have it registered as an official issue: >> >> issue: >> ------ >> It is not clearly specified how the implicit transaction context associated >> with a thread is propagated to another execution environment (at the ORB >> level) >> in case of explicit transaction propagation control. It should be clarified in >> various places, for example, that the PropagationContxt is not required to be >> transferred in case of explicit transaction propagation. >> >> >> dicussion: >> ---------- >> First, note the following two important aspects to transaction propagation: >> >> 1. Transaction Propagation Control: >> How is it controlled at the application level whether a transaction is >> propagated? -> the spec specifies implicit and explicit propagation control. >> >> 2. Transaction Context Propagation: >> How is the implicit transaction context propagated to another execution >> environement at the ORB level? -> implicit transfer of the PropagationContext >> versus explicit transfer of a Control objref (as an explicit request >> parameter). >> >> In principle, the spec could mandate that the PropagationContext is always >> transfered even when explicit transaction propagation control is used. >> Historically this was never intendend (see quoted message below). However, >> there are a lot of places where the spec speaks about implicit transfer of the >> PropagationContext without referring to implicit propagation control (Maybe >> because explicit propagation control was added at a later stage?): >> >> p. 10-60, "When the implicit context is transferred, it is represented as a >> PropagationContext." >> -> The historical intent is that in case of explicit propagation control, the >> implicit transaction context is transferred by passing the Control objref >> as an >> explicit request parameter. (Note that the implicit in 'implicit context' is >> referring to the fact that the OTS maintains implicitly transaction >> information >> with threads, its not referring to transferral. Also note that the 'implicit >> context' is referring to the transaction context, not the progagation context.) >> >> p. 10-60, "When the Control object is passed as an operation argument >> (explicit >> propagation), no special transfer mechanism is required." >> -> This could be interpreted (wrongly according to the historical intent) that >> no special transfer mechanism is required, implicit transferral of the >> PropagationContext is just fine. >> >> p. 10-61, "An interposed coordinator registers as a participant in the >> transaction with the Coordinator identified in the PropagationContext of the >> received request." >> -> but with explicit propagation it is not required that the received request >> contains a PropagationContext... >> >> p. 10-63, "When exporting a transaction, the ORB sets the PropagationContext >> into the ServiceContext::context_data field..." >> -> but this should only be required for implicit propagation control... >> >> p. 10-67, "The ORB will invoke the sender callbacks only when a transactional >> operation is issued for an object in a different process." >> -> What's the definition of a transactional operation? An operation on a >> transactional object? If yes, then this saying even in case of transactional >> objects that don't inherit TransactionalObject (ie. explicit propagation >> control), the ORB required to get the PropagationContext by using >> Sender::sending_request and to pass a PropagationContext to >> Sender::received_reply. >> >> >> ... >> >> Possible resolution: >> -------------------- >> Several people have already suggested that explicit propagation is axed from >> the OTS. >> >> ================================================================ >> >> 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 >> >> >> >> ================================================================ > > ************************************************************** Ed Cobb, Vice President, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 E-mail: ed.cobb@bea.com ************************************************************** X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 02 Nov 2000 14:24:53 -0800 To: , "Blake Biesecker" , From: Edward Cobb Subject: RE: issue 3365 -- OTS RTF issue In-Reply-To: References: <3.0.5.32.20001101154951.0098c3c0@svlhome2.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: ,\!e9iMm!!+bPe9^UH!! True. The only question is whether this is in scope for an RTF. At 05:10 PM 11/2/00 -0500, Eric Newcomer wrote: >Wasn't there some discussion about the possibility of dropping explicit >propagation altogether being easier than fixing it? > > >Eric Newcomer >IONA Technologies >200 West Street >Waltham, MA 02451 >Tel: +1 781 902 8366 >Fax: +1 781 902 8001 > >-----Original Message----- >From: Edward Cobb [mailto:ed.cobb@bea.com] >Sent: Wednesday, November 01, 2000 6:50 PM >To: Blake Biesecker; ots-rtf@omg.org >Subject: Re: issue 3365 -- OTS RTF issue > > I've never been convinced it could be made to work, but it might be >a bit >much for an RTF. > >At 12:19 PM 11/1/00 -0800, Blake Biesecker wrote: >>During the discussion on this issue the idea of explicit >>transaction propagation be dropped. Is there support >>for this idea? >> >>Blake >> >>On Wed, Mar 22, 2000 at 03:41:11PM -0500, Juergen Boldt wrote: >>> This is issue # 3365 >>> >>> OTS issue: explicit transaction propagation not clearly specified >>> >>> There has now been some discussion on this subject, therefore I would >like to >>> have it registered as an official issue: >>> >>> issue: >>> ------ >>> It is not clearly specified how the implicit transaction context >associated >>> with a thread is propagated to another execution environment (at the ORB >>> level) >>> in case of explicit transaction propagation control. It should be >clarified in >>> various places, for example, that the PropagationContxt is not required >to be >>> transferred in case of explicit transaction propagation. >>> >>> >>> dicussion: >>> ---------- >>> First, note the following two important aspects to transaction >propagation: >>> >>> 1. Transaction Propagation Control: >>> How is it controlled at the application level whether a transaction is >>> propagated? -> the spec specifies implicit and explicit propagation >control. >>> >>> 2. Transaction Context Propagation: >>> How is the implicit transaction context propagated to another execution >>> environement at the ORB level? -> implicit transfer of the >PropagationContext >>> versus explicit transfer of a Control objref (as an explicit request >>> parameter). >>> >>> In principle, the spec could mandate that the PropagationContext is >always >>> transfered even when explicit transaction propagation control is used. >>> Historically this was never intendend (see quoted message below). >However, >>> there are a lot of places where the spec speaks about implicit transfer >of the >>> PropagationContext without referring to implicit propagation control >(Maybe >>> because explicit propagation control was added at a later stage?): >>> >>> p. 10-60, "When the implicit context is transferred, it is represented >as a >>> PropagationContext." >>> -> The historical intent is that in case of explicit propagation >control, the >>> implicit transaction context is transferred by passing the Control objref >>> as an >>> explicit request parameter. (Note that the implicit in 'implicit >context' is >>> referring to the fact that the OTS maintains implicitly transaction >>> information >>> with threads, its not referring to transferral. Also note that the >'implicit >>> context' is referring to the transaction context, not the progagation >context.) >>> >>> p. 10-60, "When the Control object is passed as an operation argument >>> (explicit >>> propagation), no special transfer mechanism is required." >>> -> This could be interpreted (wrongly according to the historical >intent) that >>> no special transfer mechanism is required, implicit transferral of the >>> PropagationContext is just fine. >>> >>> p. 10-61, "An interposed coordinator registers as a participant in the >>> transaction with the Coordinator identified in the PropagationContext of >the >>> received request." >>> -> but with explicit propagation it is not required that the received >request >>> contains a PropagationContext... >>> >>> p. 10-63, "When exporting a transaction, the ORB sets the >PropagationContext >>> into the ServiceContext::context_data field..." >>> -> but this should only be required for implicit propagation control... >>> >>> p. 10-67, "The ORB will invoke the sender callbacks only when a >transactional >>> operation is issued for an object in a different process." >>> -> What's the definition of a transactional operation? An operation on a >>> transactional object? If yes, then this saying even in case of >transactional >>> objects that don't inherit TransactionalObject (ie. explicit propagation >>> control), the ORB required to get the PropagationContext by using >>> Sender::sending_request and to pass a PropagationContext to >>> Sender::received_reply. >>> >>> >>> ... >>> >>> Possible resolution: >>> -------------------- >>> Several people have already suggested that explicit propagation is axed >from >>> the OTS. >>> >>> ================================================================ >>> >>> 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 >>> >>> >>> >>> ================================================================ >> >> >************************************************************** >Ed Cobb, Vice President, Advanced Technology & Standards >BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 >Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 >E-mail: ed.cobb@bea.com >************************************************************** > > > ************************************************************** Ed Cobb, Vice President, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 E-mail: ed.cobb@bea.com ************************************************************** Date: Thu, 2 Nov 2000 14:58:54 -0800 From: Blake Biesecker To: ots-rtf@omg.org Subject: Re: issue 3365 -- OTS RTF issue Message-ID: <20001102145854.J23041@gemstone.com> References: <3.0.5.32.20001101154951.0098c3c0@svlhome2.beasys.com> <3.0.5.32.20001102142453.0510acc0@svlhome2.beasys.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <3.0.5.32.20001102142453.0510acc0@svlhome2.beasys.com>; from ed.cobb@bea.com on Thu, Nov 02, 2000 at 02:24:53PM -0800 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: QaI!!:X True. The only question is whether this is in scope for an RTF. > > At 05:10 PM 11/2/00 -0500, Eric Newcomer wrote: > >Wasn't there some discussion about the possibility of dropping explicit > >propagation altogether being easier than fixing it? > > > > > >Eric Newcomer > >IONA Technologies > >200 West Street > >Waltham, MA 02451 > >Tel: +1 781 902 8366 > >Fax: +1 781 902 8001 > > > >-----Original Message----- > >From: Edward Cobb [mailto:ed.cobb@bea.com] > >Sent: Wednesday, November 01, 2000 6:50 PM > >To: Blake Biesecker; ots-rtf@omg.org > >Subject: Re: issue 3365 -- OTS RTF issue > > > > I've never been convinced it could be made to work, but it might be > >a bit > >much for an RTF. > > > >At 12:19 PM 11/1/00 -0800, Blake Biesecker wrote: > >>During the discussion on this issue the idea of explicit > >>transaction propagation be dropped. Is there support > >>for this idea? > >> > >>Blake > >> > >>On Wed, Mar 22, 2000 at 03:41:11PM -0500, Juergen Boldt wrote: > >>> This is issue # 3365 > >>> > >>> OTS issue: explicit transaction propagation not clearly specified > >>> > >>> There has now been some discussion on this subject, therefore I would > >like to > >>> have it registered as an official issue: > >>> > >>> issue: > >>> ------ > >>> It is not clearly specified how the implicit transaction context > >associated > >>> with a thread is propagated to another execution environment (at the ORB > >>> level) > >>> in case of explicit transaction propagation control. It should be > >clarified in > >>> various places, for example, that the PropagationContxt is not required > >to be > >>> transferred in case of explicit transaction propagation. > >>> > >>> > >>> dicussion: > >>> ---------- > >>> First, note the following two important aspects to transaction > >propagation: > >>> > >>> 1. Transaction Propagation Control: > >>> How is it controlled at the application level whether a transaction is > >>> propagated? -> the spec specifies implicit and explicit propagation > >control. > >>> > >>> 2. Transaction Context Propagation: > >>> How is the implicit transaction context propagated to another execution > >>> environement at the ORB level? -> implicit transfer of the > >PropagationContext > >>> versus explicit transfer of a Control objref (as an explicit request > >>> parameter). > >>> > >>> In principle, the spec could mandate that the PropagationContext is > >always > >>> transfered even when explicit transaction propagation control is used. > >>> Historically this was never intendend (see quoted message below). > >However, > >>> there are a lot of places where the spec speaks about implicit transfer > >of the > >>> PropagationContext without referring to implicit propagation control > >(Maybe > >>> because explicit propagation control was added at a later stage?): > >>> > >>> p. 10-60, "When the implicit context is transferred, it is represented > >as a > >>> PropagationContext." > >>> -> The historical intent is that in case of explicit propagation > >control, the > >>> implicit transaction context is transferred by passing the Control objref > >>> as an > >>> explicit request parameter. (Note that the implicit in 'implicit > >context' is > >>> referring to the fact that the OTS maintains implicitly transaction > >>> information > >>> with threads, its not referring to transferral. Also note that the > >'implicit > >>> context' is referring to the transaction context, not the progagation > >context.) > >>> > >>> p. 10-60, "When the Control object is passed as an operation argument > >>> (explicit > >>> propagation), no special transfer mechanism is required." > >>> -> This could be interpreted (wrongly according to the historical > >intent) that > >>> no special transfer mechanism is required, implicit transferral of the > >>> PropagationContext is just fine. > >>> > >>> p. 10-61, "An interposed coordinator registers as a participant in the > >>> transaction with the Coordinator identified in the PropagationContext of > >the > >>> received request." > >>> -> but with explicit propagation it is not required that the received > >request > >>> contains a PropagationContext... > >>> > >>> p. 10-63, "When exporting a transaction, the ORB sets the > >PropagationContext > >>> into the ServiceContext::context_data field..." > >>> -> but this should only be required for implicit propagation control... > >>> > >>> p. 10-67, "The ORB will invoke the sender callbacks only when a > >transactional > >>> operation is issued for an object in a different process." > >>> -> What's the definition of a transactional operation? An operation on a > >>> transactional object? If yes, then this saying even in case of > >transactional > >>> objects that don't inherit TransactionalObject (ie. explicit propagation > >>> control), the ORB required to get the PropagationContext by using > >>> Sender::sending_request and to pass a PropagationContext to > >>> Sender::received_reply. > >>> > >>> > >>> ... > >>> > >>> Possible resolution: > >>> -------------------- > >>> Several people have already suggested that explicit propagation is axed > >from > >>> the OTS. > >>> > >>> ================================================================ > >>> > >>> 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 > >>> > >>> > >>> > >>> ================================================================ > >> > >> > >************************************************************** > >Ed Cobb, Vice President, Advanced Technology & Standards > >BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > >Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 > >E-mail: ed.cobb@bea.com > >************************************************************** > > > > > > > ************************************************************** > Ed Cobb, Vice President, Advanced Technology & Standards > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 > E-mail: ed.cobb@bea.com > ************************************************************** Date: Thu, 2 Nov 2000 19:46:33 -0330 From: Matthew Newhook To: Blake Biesecker Cc: ots-rtf@omg.org Subject: Re: issue 3365 -- OTS RTF issue Message-ID: <20001102194633.A31289@ooc.com> References: <3.0.5.32.20001101154951.0098c3c0@svlhome2.beasys.com> <3.0.5.32.20001102142453.0510acc0@svlhome2.beasys.com> <20001102145854.J23041@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <20001102145854.J23041@gemstone.com> Content-Type: text/plain; charset=us-ascii X-UIDL: WoSd9,%=e9! What do our AB buddies think? > > Also, does anybody know of situations where explicit propagation > is being used with success. (How many vendors are actively > interested in it?) > > Hans, since you opened the issue, does UBS actively use explicit > propagation? I'm confused. Isn't explicit propagation simply passing the Control object manually around? > Blake Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 2 Nov 2000 15:45:52 -0800 From: Blake Biesecker To: Matthew Newhook Cc: ots-rtf@omg.org Subject: Re: issue 3365 -- OTS RTF issue Message-ID: <20001102154552.M23041@gemstone.com> References: <3.0.5.32.20001101154951.0098c3c0@svlhome2.beasys.com> <3.0.5.32.20001102142453.0510acc0@svlhome2.beasys.com> <20001102145854.J23041@gemstone.com> <20001102194633.A31289@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <20001102194633.A31289@ooc.com>; from matthew@ooc.com on Thu, Nov 02, 2000 at 07:46:33PM -0330 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: BT%!!dg!e9#1#!!m7?!! On Thu, Nov 02, 2000 at 07:46:33PM -0330, Matthew Newhook wrote: > Hi, > > On Thu, Nov 02, 2000 at 02:58:54PM -0800, Blake Biesecker wrote: > > What do our AB buddies think? > > > > Also, does anybody know of situations where explicit propagation > > is being used with success. (How many vendors are actively > > interested in it?) > > > > Hans, since you opened the issue, does UBS actively use explicit > > propagation? > > I'm confused. Isn't explicit propagation simply passing the Control > object manually around? > That is what I always thought and didn't give much more thought. Issue 3365 brings up some ambiguities in the spec which prompted people to suggest that we just remove explicit propagation rather than add text every where in the spec where only implicit propagation is assumed. I tend to think that removing explicit propagation is out of the scope of an RTF, but I'd support text that clarifies explicit tx propagation. For example, if you propagate transactions by passing Control around, then you can't expect to rely on Sender/Receiver callbacks (or PI) mechanisms to track the transaction. We could remove amibiguity in the spec by describing the simple rules of explicit propagation and then saying the rest of the spec assumes implicit propagation. But first we'd need to find someone who cares enough about explicit propagation to agree to craft a proposal. Blake > > Blake > > Regards, Matthew > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: Jeffrey Mischkinsky Message-Id: <200011022346.PAA25581@wheel.dcn.davis.ca.us> Subject: Re: issue 3365 -- OTS RTF issue To: blakeb@gemstone.com (Blake Biesecker) Date: Thu, 2 Nov 2000 15:46:43 -0800 (PST) Cc: ots-rtf@omg.org In-Reply-To: <20001102145854.J23041@gemstone.com> from "Blake Biesecker" at Nov 02, 2000 02:58:54 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 5++e9F"He9`U6e9?eH!! 'Blake Biesecker' writes: > > What do our AB buddies think? Deprecate it, and see if anyone notices :-) jeff > > Also, does anybody know of situations where explicit propagation > is being used with success. (How many vendors are actively > interested in it?) > > Hans, since you opened the issue, does UBS actively use explicit > propagation? > > Blake > > On Thu, Nov 02, 2000 at 02:24:53PM -0800, Edward Cobb wrote: > > True. The only question is whether this is in scope for an RTF. > > > > At 05:10 PM 11/2/00 -0500, Eric Newcomer wrote: > > >Wasn't there some discussion about the possibility of dropping > explicit > > >propagation altogether being easier than fixing it? > > > > > > > > >Eric Newcomer > > >IONA Technologies > > >200 West Street > > >Waltham, MA 02451 > > >Tel: +1 781 902 8366 > > >Fax: +1 781 902 8001 > > > > > >-----Original Message----- > > >From: Edward Cobb [mailto:ed.cobb@bea.com] > > >Sent: Wednesday, November 01, 2000 6:50 PM > > >To: Blake Biesecker; ots-rtf@omg.org > > >Subject: Re: issue 3365 -- OTS RTF issue > > > > > > I've never been convinced it could be made to work, but > it might be > > >a bit > > >much for an RTF. > > > > > >At 12:19 PM 11/1/00 -0800, Blake Biesecker wrote: > > >>During the discussion on this issue the idea of explicit > > >>transaction propagation be dropped. Is there support > > >>for this idea? > > >> > > >>Blake > > >> > > >>On Wed, Mar 22, 2000 at 03:41:11PM -0500, Juergen Boldt wrote: > > >>> This is issue # 3365 > > >>> > > >>> OTS issue: explicit transaction propagation not clearly > specified > > >>> > > >>> There has now been some discussion on this subject, therefore > I would > > >like to > > >>> have it registered as an official issue: > > >>> > > >>> issue: > > >>> ------ > > >>> It is not clearly specified how the implicit transaction > context > > >associated > > >>> with a thread is propagated to another execution environment > (at the ORB > > >>> level) > > >>> in case of explicit transaction propagation control. It should > be > > >clarified in > > >>> various places, for example, that the PropagationContxt is not > required > > >to be > > >>> transferred in case of explicit transaction propagation. > > >>> > > >>> > > >>> dicussion: > > >>> ---------- > > >>> First, note the following two important aspects to transaction > > >propagation: > > >>> > > >>> 1. Transaction Propagation Control: > > >>> How is it controlled at the application level whether a > transaction is > > >>> propagated? -> the spec specifies implicit and explicit > propagation > > >control. > > >>> > > >>> 2. Transaction Context Propagation: > > >>> How is the implicit transaction context propagated to another > execution > > >>> environement at the ORB level? -> implicit transfer of the > > >PropagationContext > > >>> versus explicit transfer of a Control objref (as an explicit > request > > >>> parameter). > > >>> > > >>> In principle, the spec could mandate that the > PropagationContext is > > >always > > >>> transfered even when explicit transaction propagation control > is used. > > >>> Historically this was never intendend (see quoted message > below). > > >However, > > >>> there are a lot of places where the spec speaks about implicit > transfer > > >of the > > >>> PropagationContext without referring to implicit propagation > control > > >(Maybe > > >>> because explicit propagation control was added at a later > stage?): > > >>> > > >>> p. 10-60, "When the implicit context is transferred, it is > represented > > >as a > > >>> PropagationContext." > > >>> -> The historical intent is that in case of explicit > propagation > > >control, the > > >>> implicit transaction context is transferred by passing the > Control objref > > >>> as an > > >>> explicit request parameter. (Note that the implicit in > 'implicit > > >context' is > > >>> referring to the fact that the OTS maintains implicitly > transaction > > >>> information > > >>> with threads, its not referring to transferral. Also note that > the > > >'implicit > > >>> context' is referring to the transaction context, not the > progagation > > >context.) > > >>> > > >>> p. 10-60, "When the Control object is passed as an operation > argument > > >>> (explicit > > >>> propagation), no special transfer mechanism is required." > > >>> -> This could be interpreted (wrongly according to the > historical > > >intent) that > > >>> no special transfer mechanism is required, implicit > transferral of the > > >>> PropagationContext is just fine. > > >>> > > >>> p. 10-61, "An interposed coordinator registers as a > participant in the > > >>> transaction with the Coordinator identified in the > PropagationContext of > > >the > > >>> received request." > > >>> -> but with explicit propagation it is not required that the > received > > >request > > >>> contains a PropagationContext... > > >>> > > >>> p. 10-63, "When exporting a transaction, the ORB sets the > > >PropagationContext > > >>> into the ServiceContext::context_data field..." > > >>> -> but this should only be required for implicit propagation > control... > > >>> > > >>> p. 10-67, "The ORB will invoke the sender callbacks only when > a > > >transactional > > >>> operation is issued for an object in a different process." > > >>> -> What's the definition of a transactional operation? An > operation on a > > >>> transactional object? If yes, then this saying even in case of > > >transactional > > >>> objects that don't inherit TransactionalObject (ie. explicit > propagation > > >>> control), the ORB required to get the PropagationContext by > using > > >>> Sender::sending_request and to pass a PropagationContext to > > >>> Sender::received_reply. > > >>> > > >>> > > >>> ... > > >>> > > >>> Possible resolution: > > >>> -------------------- > > >>> Several people have already suggested that explicit > propagation is axed > > >from > > >>> the OTS. > > >>> > > >>> > ================================================================ > > >>> > > >>> 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 > > >>> > > >>> > > >>> > > >>> > ================================================================ > > >> > > >> > > >************************************************************** > > >Ed Cobb, Vice President, Advanced Technology & Standards > > >BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > > >Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 > > >E-mail: ed.cobb@bea.com > > >************************************************************** > > > > > > > > > > > ************************************************************** > > Ed Cobb, Vice President, Advanced Technology & Standards > > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > > Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 > > E-mail: ed.cobb@bea.com > > ************************************************************** > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Fri, 3 Nov 2000 16:27:45 +1000 From: Ted McFadden To: Jeffrey Mischkinsky Cc: Blake Biesecker , ots-rtf@omg.org Subject: Re: issue 3365 -- OTS RTF issue Message-ID: <20001103162745.A24067@ooc.com.au> Mail-Followup-To: Jeffrey Mischkinsky , Blake Biesecker , ots-rtf@omg.org References: <20001102145854.J23041@gemstone.com> <200011022346.PAA25581@wheel.dcn.davis.ca.us> Mime-Version: 1.0 X-Mailer: Mutt 1.0i In-Reply-To: <200011022346.PAA25581@wheel.dcn.davis.ca.us>; from jmischki@wheel.dcn.davis.ca.us on Thu, Nov 02, 2000 at 03:46:43PM -0800 Content-Type: text/plain; charset=us-ascii X-UIDL: M+Td9j-Md9EU~!!*])e9 On Thu, Nov 02, 2000 at 03:46:43PM -0800, Jeffrey Mischkinsky wrote: > 'Blake Biesecker' writes: > > > > What do our AB buddies think? > > Deprecate it, and see if anyone notices :-) > > jeff > Hi, I'm not sure there is any way to effectively deprecate explicit propagation as long as anything besides CosTransactions::Current is required to perform all transactional operations. Once a Control, Coordinator, or Terminator are passed as a parameter propagation is explicit. I can't see how to prevent that without major surgery on the Current interface. Another problem I see with deprecating the explicit model is that we are then requiring a client side implicit OTS implementation in order to be able to use OTS at all. With explicit, for example, our C++ OTS Server/TransactionFactory can be used with any vendor's corba client in *any* language right now. With implicit, there would have to be a language specific client side runtime available for anyone who wanted to use our C++ server. This is not a terribly attractive situation. Cheers, Ted > > > > > Hans, since you opened the issue, does UBS actively use explicit > > propagation? > > > > Blake > > > > On Thu, Nov 02, 2000 at 02:24:53PM -0800, Edward Cobb wrote: > > > True. The only question is whether this is in scope for an RTF. > > > > > > At 05:10 PM 11/2/00 -0500, Eric Newcomer wrote: > > > >Wasn't there some discussion about the possibility of dropping explicit > > > >propagation altogether being easier than fixing it? > > > > > > > > > > > >Eric Newcomer > > > >IONA Technologies > > > >200 West Street > > > >Waltham, MA 02451 > > > >Tel: +1 781 902 8366 > > > >Fax: +1 781 902 8001 > > > > > > > >-----Original Message----- > > > >From: Edward Cobb [mailto:ed.cobb@bea.com] > > > >Sent: Wednesday, November 01, 2000 6:50 PM > > > >To: Blake Biesecker; ots-rtf@omg.org > > > >Subject: Re: issue 3365 -- OTS RTF issue > > > > > > > > I've never been convinced it could be made to work, but it might be > > > >a bit > > > >much for an RTF. > > > > > > > >At 12:19 PM 11/1/00 -0800, Blake Biesecker wrote: > > > >>During the discussion on this issue the idea of explicit > > > >>transaction propagation be dropped. Is there support > > > >>for this idea? > > > >> > > > >>Blake > > > >> > > > >>On Wed, Mar 22, 2000 at 03:41:11PM -0500, Juergen Boldt wrote: > > > >>> This is issue # 3365 > > > >>> > > > >>> OTS issue: explicit transaction propagation not clearly specified > > > >>> > > > >>> There has now been some discussion on this subject, therefore I would > > > >like to > > > >>> have it registered as an official issue: > > > >>> > > > >>> issue: > > > >>> ------ > > > >>> It is not clearly specified how the implicit transaction context > > > >associated > > > >>> with a thread is propagated to another execution environment (at the ORB > > > >>> level) > > > >>> in case of explicit transaction propagation control. It should be > > > >clarified in > > > >>> various places, for example, that the PropagationContxt is not required > > > >to be > > > >>> transferred in case of explicit transaction propagation. > > > >>> > > > >>> > > > >>> dicussion: > > > >>> ---------- > > > >>> First, note the following two important aspects to transaction > > > >propagation: > > > >>> > > > >>> 1. Transaction Propagation Control: > > > >>> How is it controlled at the application level whether a transaction is > > > >>> propagated? -> the spec specifies implicit and explicit propagation > > > >control. > > > >>> > > > >>> 2. Transaction Context Propagation: > > > >>> How is the implicit transaction context propagated to another execution > > > >>> environement at the ORB level? -> implicit transfer of the > > > >PropagationContext > > > >>> versus explicit transfer of a Control objref (as an explicit request > > > >>> parameter). > > > >>> > > > >>> In principle, the spec could mandate that the PropagationContext is > > > >always > > > >>> transfered even when explicit transaction propagation control is used. > > > >>> Historically this was never intendend (see quoted message below). > > > >However, > > > >>> there are a lot of places where the spec speaks about implicit transfer > > > >of the > > > >>> PropagationContext without referring to implicit propagation control > > > >(Maybe > > > >>> because explicit propagation control was added at a later stage?): > > > >>> > > > >>> p. 10-60, "When the implicit context is transferred, it is represented > > > >as a > > > >>> PropagationContext." > > > >>> -> The historical intent is that in case of explicit propagation > > > >control, the > > > >>> implicit transaction context is transferred by passing the Control objref > > > >>> as an > > > >>> explicit request parameter. (Note that the implicit in 'implicit > > > >context' is > > > >>> referring to the fact that the OTS maintains implicitly transaction > > > >>> information > > > >>> with threads, its not referring to transferral. Also note that the > > > >'implicit > > > >>> context' is referring to the transaction context, not the progagation > > > >context.) > > > >>> > > > >>> p. 10-60, "When the Control object is passed as an operation argument > > > >>> (explicit > > > >>> propagation), no special transfer mechanism is required." > > > >>> -> This could be interpreted (wrongly according to the historical > > > >intent) that > > > >>> no special transfer mechanism is required, implicit transferral of the > > > >>> PropagationContext is just fine. > > > >>> > > > >>> p. 10-61, "An interposed coordinator registers as a participant in the > > > >>> transaction with the Coordinator identified in the PropagationContext of > > > >the > > > >>> received request." > > > >>> -> but with explicit propagation it is not required that the received > > > >request > > > >>> contains a PropagationContext... > > > >>> > > > >>> p. 10-63, "When exporting a transaction, the ORB sets the > > > >PropagationContext > > > >>> into the ServiceContext::context_data field..." > > > >>> -> but this should only be required for implicit propagation control... > > > >>> > > > >>> p. 10-67, "The ORB will invoke the sender callbacks only when a > > > >transactional > > > >>> operation is issued for an object in a different process." > > > >>> -> What's the definition of a transactional operation? An operation on a > > > >>> transactional object? If yes, then this saying even in case of > > > >transactional > > > >>> objects that don't inherit TransactionalObject (ie. explicit propagation > > > >>> control), the ORB required to get the PropagationContext by using > > > >>> Sender::sending_request and to pass a PropagationContext to > > > >>> Sender::received_reply. > > > >>> > > > >>> > > > >>> ... > > > >>> > > > >>> Possible resolution: > > > >>> -------------------- > > > >>> Several people have already suggested that explicit propagation is axed > > > >from > > > >>> the OTS. > > > >>> > > > >>> ================================================================ > > > >>> > > > >>> 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 > > > >>> > > > >>> > > > >>> > > > >>> ================================================================ > > > >> > > > >> > > > >************************************************************** > > > >Ed Cobb, Vice President, Advanced Technology & Standards > > > >BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > > > >Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 > > > >E-mail: ed.cobb@bea.com > > > >************************************************************** > > > > > > > > > > > > > > > ************************************************************** > > > Ed Cobb, Vice President, Advanced Technology & Standards > > > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > > > Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 > > > E-mail: ed.cobb@bea.com > > > ************************************************************** > > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff@persistence.com +1 650-372-3604 -- Ted McFadden tmcf@ooc.com.au Object Oriented Concepts http://www.ooc.com Suite 4 904 Stanley St. +61-7-3891-5744 East Brisbane 4169, QLD. Australia From: "Mark Little" To: "Matthew Newhook" , "Blake Biesecker" Cc: References: <3.0.5.32.20001101154951.0098c3c0@svlhome2.beasys.com> <3.0.5.32.20001102142453.0510acc0@svlhome2.beasys.com> <20001102145854.J23041@gemstone.com> <20001102194633.A31289@ooc.com> Subject: Re: issue 3365 -- OTS RTF issue Date: Fri, 3 Nov 2000 09:21:42 -0000 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 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: cQ^!!C+Ld9'cV!!4IVd9 Sorry, missed the start of this thread. > > Also, does anybody know of situations where explicit propagation > > is being used with success. (How many vendors are actively > > interested in it?) Yes, we have been using it for about 4 years now. Depending upon the ORB you want our transaction service to run on it can be the only way to propagate the context. > > > > Hans, since you opened the issue, does UBS actively use explicit > > propagation? > > I'm confused. Isn't explicit propagation simply passing the Control > object manually around? Yup. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Architect (Transactions), Arjuna Solutions PHONE : +44 191 2308034, FAX : +44 191 2308035 EMAIL : mark@arjuna.com From: "Peter Furniss" To: "Matthew Newhook" , "Blake Biesecker" Cc: Subject: RE: issue 3365 -- OTS RTF issue Date: Sat, 4 Nov 2000 01:54:26 -0000 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.2911.0) In-Reply-To: <20001102194633.A31289@ooc.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Content-Type: text/plain; charset="us-ascii" X-UIDL: \@2!!8Znd9Q>+e9V2Ie9 Matthew Newhook sent: > I'm confused. Isn't explicit propagation simply passing the Control > object manually around? or, slightly less wisely, the Coordinator. And, since any Resource-creator needs to get at the Coordinator reference to do the register_resource, and the Coordinator reference could then be passed as a parameter, it's probably impossible to completely prohibit explicit propagation even with radical surgery on the Current interface. I suggest: The possibility of explicit propagation is an implicit capability of an interoperable OTS. :-) Peter Reply-To: From: "Eric Newcomer" To: "Peter Furniss" , "Matthew Newhook" , "Blake Biesecker" Cc: Subject: RE: issue 3365 -- OTS RTF issue Date: Fri, 3 Nov 2000 22:25:32 -0500 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Importance: Normal Content-Type: text/plain; charset="us-ascii" X-UIDL: :@p!!+82e9~=0!!@aad9 Yes, actually considering the discussion to date I would actually oppose dropping explicit context propagation. It may be beyond the scope of an RTF, and as Peter says it is probably a requirement for interoperability. Eric Newcomer IONA Technologies 200 West Street Waltham, MA 02451 Tel: +1 781 902 8366 Fax: +1 781 902 8001 -----Original Message----- From: Peter Furniss [mailto:peter.furniss@arjuna.com] Sent: Friday, November 03, 2000 8:54 PM To: Matthew Newhook; Blake Biesecker Cc: ots-rtf@omg.org Subject: RE: issue 3365 -- OTS RTF issue Matthew Newhook sent: > I'm confused. Isn't explicit propagation simply passing the Control > object manually around? or, slightly less wisely, the Coordinator. And, since any Resource-creator needs to get at the Coordinator reference to do the register_resource, and the Coordinator reference could then be passed as a parameter, it's probably impossible to completely prohibit explicit propagation even with radical surgery on the Current interface. I suggest: The possibility of explicit propagation is an implicit capability of an interoperable OTS. :-) Peter From: hans.kneubuehl@ubs.com Received: from unknown(160.59.228.7) by uranus via smap (V5.5) id xma029987; Mon, 6 Nov 00 16:17:06 +0100 Received: from localhost (root@localhost) by hermes3.flur.zuerich.ubs.ch (8.9.3 (PHNE_21697)/8.9.3) with ESMTP id QAA21272; Mon, 6 Nov 2000 16:16:34 +0100 (MET) X-OpenMail-Hops: 2 Date: Mon, 6 Nov 2000 16:16:30 +0100 Message-Id: Subject: RE: Re: issue 3365 -- OTS RTF issue MIME-Version: 1.0 TO: blakeb@gemstone.com, ots-rtf@omg.org CC: hans-peter.hoidn@ubs.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Mon, 6 Nov 2000 16:16:30 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: I6n!!$P+e9)$R!!~TGe9 > -----Original Message----- > From: blakeb [mailto:blakeb@gemstone.com] > Sent: Thursday, November 02, 2000 11:59 PM > > Hans, since you opened the issue, does UBS actively use explicit > propagation? > No, we don't. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11