Issue 2931: locality constraints (ots-rtf) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi@triodia.com) Nature: Uncategorized Issue Severity: Summary: The spec says the following about locality constraints: Page 10-14: An implementation of the Transaction Service may restrict the ability for some or all of these objects to be transmitted to or used in other execution environments, to enable it to guarantee transaction integrity. [ The objects affected by this clause appear to be TransactionFactory, Control, Resource, Terminator, and Coordinator. ] However: Page 10-14: An application can propagate a transaction context by passing the Control as an explicit request parameter. [...] When a Control is transferred between execution environments [...]. Either I can propagate a transaction context by passing a Control object, or I cannot. At the very least, the spec must state clearly which objects are and are not locality constrained, otherwise I can't write portable code. Resolution: resolved, see below Revised Text: The text allowing a Transaction Service to restrict the transmission of context management objects (TransactionFactory, Control, Resource, Terminator, and Coordinator) will be removed. None of these objects should have locality constraints. Revised Text: Remove the third paragraph of section 10.2.3 Context management: Page 10-14: An implementation of the Transaction Service may restrict the ability for some or all of these objects to be transmitted to or used in other execution environments, to enable it to guarantee transaction integrity. (This is on page 10-14 of formal/97-12-17 and ptc/99-10-07.) Actions taken: October 11, 1999: received issue January 16, 2001: closed issue Discussion: End of Annotations:===== Date: Mon, 11 Oct 1999 14:07:10 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: issues@omg.org Subject: ots-rtf: locality constraints Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The spec says the following about locality constraints: Page 10-14: An implementation of the Transaction Service may restrict the ability for some or all of these objects to be transmitted to or used in other execution environments, to enable it to guarantee transaction integrity. [ The objects affected by this clause appear to be TransactionFactory, Control, Resource, Terminator, and Coordinator. ] However: Page 10-14: An application can propagate a transaction context by passing the Control as an explicit request parameter. [...] When a Control is transferred between execution environments [...]. Either I can propagate a transaction context by passing a Control object, or I cannot. At the very least, the spec must state clearly which objects are and are not locality constrained, otherwise I can't write portable code. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Feb 2000 14:38:53 -0800 To: Blake Biesecker From: Edward Cobb Subject: Re: Issue 2931: locality constraints Cc: ots-rtf@omg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: ln\d9B'B!!;SB!!-=0e9 Some more history. Even though explicit propagation is a technology that has never been shown to work in practice and is certainly not available commercially from any vendor claiming transaction integrity as understood by those of us in the business, it is more appealing to OO purists than hidden context associated with threads (what's a thread in OO speak anyway?). OTS was the first service to introduce hidden context. Since them, many others have as well. The price for being first was inclusion of the more purist view. If you want to do everyone a real service, we should remove it (as well as the notion of un-checked transactions) from the specification. Someone else, however, I don't feel strongly about this topic :) At 05:24 PM 2/8/00 -0800, you wrote: >Michi brings up a good point. This section is confusing. >Do the original writers of the spec know why this first >paragraph Michi mentions was added to the spec? > >It seems to be that this was added to allow some >implementions to "break" the rules if data integrity >is an issue. Do people still see a need for this >kind of loop hole? > >Blake > > >issue archive: >--------------------------------- > >Issue 2931: locality constraints (ots-rtf) >Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) >Nature: Uncategorized Issue >Severity: >Summary: The spec says the following about locality constraints: > > Page 10-14: > > An implementation of the Transaction Service may restrict the > ability for some or all of these objects to be transmitted to > or used in other execution environments, to enable it to guarantee > transaction integrity. > > [ The objects affected by this clause appear to be TransactionFactory, > Control, Resource, Terminator, and Coordinator. ] > >However: > > Page 10-14: > > An application can propagate a transaction context by passing > the Control as an explicit request parameter. [...] When a Control > is transferred between execution environments [...]. > > >Either I can propagate a transaction context by passing a Control object, >or I cannot. At the very least, the spec must state clearly which >objects are and are not locality constrained, otherwise I can't write >portable code. >Resolution: >Revised Text: >Actions taken: >October 11, 1999: received issue >Discussion: > >End of Annotations:===== >Date: Mon, 11 Oct 1999 14:07:10 +1000 (EST) >From: Michi Henning >X-Sender: michi@bobo.triodia.com >To: issues@omg.org >Subject: ots-rtf: locality constraints >Message-ID: >Organization: Object Oriented Concepts >MIME-Version: 1.0 >Content-Type: TEXT/PLAIN; charset=US-ASCII >X-UIDL: i&J!!+5cd9),'!!9/5e9 > > >The spec says the following about locality constraints: > > Page 10-14: > > An implementation of the Transaction Service may restrict the > ability for some or all of these objects to be transmitted to > or used in other execution environments, to enable it to >guarantee > transaction integrity. > > [ The objects affected by this clause appear to be >TransactionFactory, > Control, Resource, Terminator, and Coordinator. ] > >However: > > Page 10-14: > > An application can propagate a transaction context by passing > the Control as an explicit request parameter. [...] When a >Control > is transferred between execution environments [...]. > > >Either I can propagate a transaction context by passing a Control >object, >or I cannot. At the very least, the spec must state clearly which >objects are and are not locality constrained, otherwise I can't write >portable code. > > Cheers, > > Michi. >-- >Michi Henning +61 7 3236 1633 >Object Oriented Concepts +61 4 1118 2700 (mobile) >PO Box 372 +61 7 3211 0047 (fax) >Annerley 4103 michi@ooc.com.au >AUSTRALIA http://www.ooc.com > > > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Thu, 10 Feb 2000 08:56:21 +1000 (EST) From: Michi Henning To: Edward Cobb cc: Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 2931: locality constraints In-Reply-To: <3.0.5.32.20000209143853.009d9100@svlhome2.beasys.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Zb=e91nPe9`dCe9$=Ce9 On Wed, 9 Feb 2000, Edward Cobb wrote: > If you want to do everyone a real service, we should remove it (as well as > the notion of un-checked transactions) from the specification. Someone > else, however, I don't feel strongly about this topic :) I would support this, I think. It would result in a cleaner and simpler service, and would remove the strange conflict between checked behavior and suspend/resume. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 9 Feb 2000 18:19:24 -0800 From: Blake Biesecker To: Michi Henning Cc: Edward Cobb , ots-rtf@omg.org Subject: Re: Issue 2931: locality constraints Message-ID: <20000209181924.A2919@gemstone.com> References: <3.0.5.32.20000209143853.009d9100@svlhome2.beasys.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from michi@ooc.com.au on Thu, Feb 10, 2000 at 08:56:21AM +1000 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: @D:e9%8$!!\KJ!!TE*e9 On Thu, Feb 10, 2000 at 08:56:21AM +1000, Michi Henning wrote: > On Wed, 9 Feb 2000, Edward Cobb wrote: > > > If you want to do everyone a real service, we should remove it > (as well as > > the notion of un-checked transactions) from the > specification. Someone > > else, however, I don't feel strongly about this topic :) > > I would support this, I think. It would result in a cleaner and > simpler > service, and would remove the strange conflict between checked > behavior > and suspend/resume. > > Cheers, > > Michi. > I think we can resolve issue 2931, but proposing to remove this text from the OTS spec: Page 10-14: An implementation of the Transaction Service may restrict the ability for some or all of these objects to be transmitted to or used in other execution environments, to enable it to guarantee transaction integrity. Unless I hear strenuous objections, this will be what we vote on. As for un-checked transactions, while on the surface it seems like a good idea, I haven't personally had the time to think it all through. If either of you think it is something we should pursue, I think you should open a separate issue. Also, since unchecked transactions are mentioned in several places in the text, it will require more complicated changes than just fixing the locality constraint issue. Blake Date: Thu, 10 Feb 2000 12:39:15 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: Edward Cobb , ots-rtf@omg.org Subject: Re: Issue 2931: locality constraints In-Reply-To: <20000209181924.A2919@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: k;%!!L,*e9Pk]!!f%Qd9 On Wed, 9 Feb 2000, Blake Biesecker wrote: > I think we can resolve issue 2931, but proposing to remove this text > from the OTS spec: > > Page 10-14: > > > > An implementation of the Transaction Service may restrict > the > ability for some or all of these objects to be transmitted > to > or used in other execution environments, to enable it to > guarantee > transaction integrity. > > > Unless I hear strenuous objections, this will be what we vote on. Is that good enough? Don't we also need to make it clear which object types (if any) are locality constrained? Should we use local interfaces for locality-constrained objects? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 10 Feb 2000 13:22:27 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: Edward Cobb , ots-rtf@omg.org Subject: Re: Issue 2931: locality constraints In-Reply-To: <20000209191935.C2929@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: XXZ!!E\Ee9IV!!!>oK!! On Wed, 9 Feb 2000, Blake Biesecker wrote: > Removing this text removes all notion of locality from this section. > Are you interested suggesting a locally constrained scheme? If so, > what do you have in mind? Nothing in particular. If we remove all reference to locality, then, by implication, all object types are fully-fledged types that can be passed over the wire. Is that what we want? What about Current? Cheers, Michi. Date: Wed, 9 Feb 2000 19:19:35 -0800 From: Blake Biesecker To: Michi Henning Cc: Edward Cobb , ots-rtf@omg.org Subject: Re: Issue 2931: locality constraints Message-ID: <20000209191935.C2929@gemstone.com> References: <20000209181924.A2919@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from michi@ooc.com.au on Thu, Feb 10, 2000 at 12:39:15PM +1000 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: ednd9I%jd9I[ad9E/hd9 On Thu, Feb 10, 2000 at 12:39:15PM +1000, Michi Henning wrote: > On Wed, 9 Feb 2000, Blake Biesecker wrote: > > > I think we can resolve issue 2931, but proposing to remove this > text > > from the OTS spec: > > > > Page 10-14: > > > > > > An implementation of the Transaction Service may restrict > the > > ability for some or all of these objects to be transmitted > to > > or used in other execution environments, to enable it to > guarantee > > transaction integrity. > > > > > Unless I hear strenuous objections, this will be what we vote on. > > Is that good enough? Don't we also need to make it clear which > object types > (if any) are locality constrained? Should we use local interfaces > for > locality-constrained objects? > Removing this text removes all notion of locality from this section. Are you interested suggesting a locally constrained scheme? If so, what do you have in mind? Blake > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html > Date: Wed, 9 Feb 2000 19:37:46 -0800 From: Blake Biesecker To: Michi Henning Cc: Edward Cobb , ots-rtf@omg.org Subject: Re: Issue 2931: locality constraints Message-ID: <20000209193746.D2929@gemstone.com> References: <20000209191935.C2929@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from michi@ooc.com.au on Thu, Feb 10, 2000 at 01:22:27PM +1000 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: U~Zd9aA6!!57[!!2X>!! On Thu, Feb 10, 2000 at 01:22:27PM +1000, Michi Henning wrote: > On Wed, 9 Feb 2000, Blake Biesecker wrote: > > > Removing this text removes all notion of locality from this > section. > > Are you interested suggesting a locally constrained scheme? If so, > > what do you have in mind? > > Nothing in particular. If we remove all reference to locality, then, > by implication, all object types are fully-fledged types that can be > passed over the wire. Is that what we want? What about Current? > > Cheers, > > Michi. > But Current is not referenced by the text that I'm proposing to remove. I definitely think that Current should be locally constrained but isn't that taken care of somewhere else in the spec? If it isn't then I think that is a separate issue, since this section as it stands doesn't constrain Current. As mentioned when this issue was opened (by you I believe): [ The objects affected by this clause appear to be TransactionFactory, Control, Resource, Terminator, and Coordinator. ] Blake Sender: jon@corvette.floorboard.com Message-ID: <38A23B4D.3327DF91@floorboard.com> Date: Wed, 09 Feb 2000 20:15:09 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Blake Biesecker CC: Michi Henning , Edward Cobb , ots-rtf@omg.org Subject: Re: Issue 2931: locality constraints References: <20000209191935.C2929@gemstone.com> <20000209193746.D2929@gemstone.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 6B@e9n>3!!*MV!!i But Current is not referenced by the text that I'm proposing to > remove. > > I definitely think that Current should be locally constrained > but isn't that taken care of somewhere else in the spec? If it > isn't then I think that is a separate issue, since this section > as it stands doesn't constrain Current. Yes. The Core, section 4.8 states that any interface derived from CORBA::Current is locality constrained already. Although it never hurts to repeat it. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 10 Feb 2000 14:28:22 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Blake Biesecker , Edward Cobb , ots-rtf@omg.org Subject: Re: Issue 2931: locality constraints In-Reply-To: <38A23B4D.3327DF91@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: G^n!!:o!!!f+Je9++R!! On Wed, 9 Feb 2000, Jonathan Biggar wrote: > > I definitely think that Current should be locally constrained > > but isn't that taken care of somewhere else in the spec? If it > > isn't then I think that is a separate issue, since this section > > as it stands doesn't constrain Current. > > Yes. The Core, section 4.8 states that any interface derived from > CORBA::Current is locality constrained already. Although it never > hurts > to repeat it. Great. So, are we agreed then? Everything is an ordinary object except for Current? Cheers, Michi. From: "Mark Little" To: "Blake Biesecker" , "Michi Henning" Cc: "Edward Cobb" , References: <3.0.5.32.20000209143853.009d9100@svlhome2.beasys.com> <20000209181924.A2919@gemstone.com> Subject: Re: Issue 2931: locality constraints Date: Thu, 10 Feb 2000 09:27:24 -0000 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: p/_d92%[!!1@F!!nW!!! ----- Original Message ----- > I think we can resolve issue 2931, but proposing to remove this text > from the OTS spec: > > Page 10-14: > > An implementation of the Transaction Service may restrict > the > ability for some or all of these objects to be transmitted > to > or used in other execution environments, to enable it to > guarantee > transaction integrity. > > Unless I hear strenuous objections, this will be what we vote on. > > As for un-checked transactions, while on the surface it seems like a > good > idea, I haven't personally had the time to think it all through. If > either of you think it is something we should pursue, I think you > should open a separate issue. Also, since unchecked transactions > are mentioned in several places in the text, it will require > more complicated changes than just fixing the locality constraint > issue. Does this mean that an OTS implementation cannot restrict the ability to send some of these interfaces? I'm thinking more about the Terminator that appears in the propagation context. I know of several implementations that don't send that in order to prevent servers from terminating the transaction. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk From: "Mark Little" To: "Blake Biesecker" , "Edward Cobb" Cc: References: <3.0.5.32.20000209143853.009d9100@svlhome2.beasys.com> Subject: Re: Issue 2931: locality constraints Date: Thu, 10 Feb 2000 09:49:52 -0000 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: $\Ge9A()e9!''e96_F!! ----- Original Message ----- > Some more history. > Even though explicit propagation is a technology that has never been > shown > to work in practice and is certainly not available commercially from > any > vendor claiming transaction integrity as understood by those of us > in the > business, it is more appealing to OO purists than hidden context associated > with threads (what's a thread in OO speak anyway?). OTS was the > first > service to introduce hidden context. Since them, many others have as > well. > The price for being first was inclusion of the more purist view. > If you want to do everyone a real service, we should remove it (as > well as > the notion of un-checked transactions) from the > specification. Someone > else, however, I don't feel strongly about this topic :) Agreed. If you want to do something that will go "un-checked" then you can always suspend/resume. However, as Blak pointed out, removing checked from the spec. may be difficult. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 10 Feb 2000 10:26:17 -0800 To: Michi Henning , Blake Biesecker From: Edward Cobb Subject: Re: Issue 2931: locality constraints Cc: ots-rtf@omg.org In-Reply-To: References: <20000209181924.A2919@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: J<6e9e^h!!c~i!!5)-e9 We really can't use local interfaces until the components FTF completes. At present, only the Current interface is identified as a local interface in the components changes to OTS. At 12:39 PM 2/10/00 +1000, Michi Henning wrote: >On Wed, 9 Feb 2000, Blake Biesecker wrote: > >> I think we can resolve issue 2931, but proposing to remove this text >> from the OTS spec: >> >> Page 10-14: >> >> An implementation of the Transaction Service may restrict the >> ability for some or all of these objects to be transmitted to >> or used in other execution environments, to enable it to guarantee >> transaction integrity. >> >> Unless I hear strenuous objections, this will be what we vote on. > >Is that good enough? Don't we also need to make it clear which object >> types >(if any) are locality constrained? Should we use local interfaces for >locality-constrained objects? > > Cheers, > > Michi. >-- >Michi Henning +61 7 3891 5744 >Object Oriented Concepts +61 4 1118 2700 (mobile) >Suite 4, 904 Stanley St +61 7 3891 5009 (fax) >East Brisbane 4169 michi@ooc.com.au >AUSTRALIA >> http://www.ooc.com.au/staff/michi-henning.html > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Thu, 10 Feb 2000 11:14:18 -0800 From: Blake Biesecker To: Mark Little Cc: Michi Henning , Edward Cobb , ots-rtf@omg.org Subject: Re: Issue 2931: locality constraints Message-ID: <20000210111417.B3389@gemstone.com> References: <3.0.5.32.20000209143853.009d9100@svlhome2.beasys.com> <20000209181924.A2919@gemstone.com> <0bfc01bf73a9$0a66f4d0$6e96f080@ncl.ac.uk> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <0bfc01bf73a9$0a66f4d0$6e96f080@ncl.ac.uk>; from M.C.Little@ncl.ac.uk on Thu, Feb 10, 2000 at 09:27:24AM -0000 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: M#De9jeGe98H[!!;!kd9 On Thu, Feb 10, 2000 at 09:27:24AM -0000, Mark Little wrote: > > ----- Original Message ----- > > > I think we can resolve issue 2931, but proposing to remove this > text > > from the OTS spec: > > > > Page 10-14: > > > > An implementation of the Transaction Service may restrict > the > > ability for some or all of these objects to be transmitted > to > > or used in other execution environments, to enable it to > guarantee > > transaction integrity. > > > > Unless I hear strenuous objections, this will be what we vote on. > > > > As for un-checked transactions, while on the surface it seems like > a good > > idea, I haven't personally had the time to think it all > through. If > > either of you think it is something we should pursue, I think you > > should open a separate issue. Also, since unchecked transactions > > are mentioned in several places in the text, it will require > > more complicated changes than just fixing the locality constraint > > issue. > > Does this mean that an OTS implementation cannot restrict the > ability to > send some of these interfaces? I'm thinking more about the > Terminator that > appears in the propagation context. I know of several > implementations that > don't send that in order to prevent servers from terminating the > transaction. > > Mark. > >From page 10-14 (referring to the Coordinator and the Terminator): These two objects can be propagated independently, allowing finer granularity control over propagation. This text will not be removed and seems to allow not propagating the Terminator. Blake From: "Mark Little" To: "Blake Biesecker" Cc: "Michi Henning" , "Edward Cobb" , References: <3.0.5.32.20000209143853.009d9100@svlhome2.beasys.com> <20000209181924.A2919@gemstone.com> <0bfc01bf73a9$0a66f4d0$6e96f080@ncl.ac.uk> <20000210111417.B3389@gemstone.com> Subject: Re: Issue 2931: locality constraints Date: Fri, 11 Feb 2000 09:11:24 -0000 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: L,B!!PMk!!\bi!!+WMd9 ----- Original Message ----- > > Does this mean that an OTS implementation cannot restrict the ability to > > send some of these interfaces? I'm thinking more about the Terminator that > > appears in the propagation context. I know of several implementations that > > don't send that in order to prevent servers from terminating the > > transaction. > > > > Mark. > > > > From page 10-14 (referring to the Coordinator and the Terminator): > > These two objects can be propagated independently, allowing > finer granularity control over propagation. > > This text will not be removed and seems to allow not propagating the > Terminator. In which case I don't have a problem with the proposed change. All the best, Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk