Issue 3417: TransactionalObject remnants (ots-rtf) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi@triodia.com) Nature: Uncategorized Issue Severity: Summary: On page 10-35 of ptc/99-10-07, the text talks about TransactionalObject at the bottom of the page. However, TransactionalObject is deleted at the top of the page, so the two edits don't go together. Also, near the bottom of the page, we have: "In CORBA today, an object declares..." This will be completely meaningless in two years' time. If anything, such things must be expressed in terms of version numbers for the spec. Resolution: resolved, see below Revised Text: In section 10.3.10, under the heading "Design Rationale", change the second paragraph from: "In CORBA today, an object declares its ability to support a shared transaction by inheriting from the TransactionalObject interface. Such an object will always receive a shared transaction if one is active, but will not receive one when there is no active transaction. This behavior is more accurately described as allowing a shared transaction, since the object may or may not receive a shared transaction. Today s CORBA does not provide a mechanism to require a shared transaction at invocation time since an object which does not inherit from TransactionalObject may not receive a shared transaction, even when one is active. This produces the following two by two matrix of possible choices for shared transaction support: " to: "In OTS 1.0 and OTS 1.1, an object declared its ability to support a shared transaction by inheriting from an empty interface called TransactionalObject. Such an object always received a shared transaction if one was active, but did not receive one when there was no active transaction. This behavior is more accurately described as allowing a shared transaction, since such an object may or may not receive a shared transaction. OTS 1.0 and OTS 1.1 did not provide a mechanism to require a shared transaction at invocation time since an object which did not inherit from the TransactionalObject interface was not required to receive a shared transaction, even when one was active. This behavior produces the following two by two matrix of possible choices for shared transaction support: " Actions taken: March 14, 2000: received issue January 16, 2001: closed issue Discussion: Phrases like "CORBA today" will be changes to "CORBA 2.3". TransactionalObject will be briefly explained in the passage mentioned in the summary so that it can be understood by those unfamiliar with CORBA 2.3. End of Annotations:===== Date: Tue, 14 Mar 2000 13:02:28 +1000 (EST) From: Michi Henning Reply-To: ots-rtf@omg.org To: ots-rtf@omg.org cc: issues@omg.org Subject: TransactionalObject remnants Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: $2(!!(Ci!!@PDe92J^!! On page 10-35 of ptc/99-10-07, the text talks about TransactionalObject at the bottom of the page. However, TransactionalObject is deleted at the top of the page, so the two edits don't go together. Also, near the bottom of the page, we have: "In CORBA today, an object declares..." This will be completely meaningless in two years' time. If anything, such things must be expressed in terms of version numbers for the spec. 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, 3 May 2000 18:56:08 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: Issue 3417 - TransactionalObject remnants Message-ID: <20000503185608.C13684@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: 2O0!!I8*!!#H]d9N4Wd9 Here is my first pass at addressing the problems with the text on page 10-35 this issue point out. My goal was to make this passage able to stand on its own regardless of whether the TransactionalObject IDL is removed from the 2.4 specification. Do people feel this is sufficient? Blake Issue 3417: TransactionalObject remnants (ots-rtf) Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: On page 10-35 of ptc/99-10-07, the text talks about TransactionalObject at the bottom of the page. However, TransactionalObject is deleted at the top of the page, so the two edits don't go together. Also, near the bottom of the page, we have: "In CORBA today, an object declares..." This will be completely meaningless in two years' time. If anything, such things must be expressed in terms of version numbers for the spec. Resolution: Phrases like "CORBA today" will be changes to "CORBA 2.3". TransactionalObject will be briefly explained in the passage mentioned in the summary so that it can be understood by those unfamiliar with CORBA 2.3. Revised Text: In section 10.3.10, under the heading "Design Rationale", change the second paragraph from: "In CORBA today, an object declares its ability to support a shared transaction by inheriting from the TransactionalObject interface. Such an object will always receive a shared transaction if one is active, but will not receive one when there is no active transaction. This behavior is more accurately described as allowing a shared transaction, since the object may or may not receive a shared transaction. Today s CORBA does not provide a mechanism to require a shared transaction at invocation time since an object which does not inherit from TransactionalObject may not receive a shared transaction, even when one is active. This produces the following two by two matrix of possible choices for shared transaction support: " to: "In CORBA 2.3, an object declared its ability to support a shared transaction by inheriting from an empty interface called TransactionalObject. Such an object always received a shared transaction if one was active, but did not receive one when there was no active transaction. This behavior is more accurately described as allowing a shared transaction, since such an object may or may not receive a shared transaction. CORBA 2.3 and before did not provide a mechanism to require a shared transaction at invocation time since an object which did not inherit from the TransactionalObject interface was not able to receive a shared transaction, even when one was active. This behavior produces the following two by two matrix of possible choices for shared transaction support: " Actions taken: March 14, 2000: received issue Date: Thu, 4 May 2000 12:02:42 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: ots-rtf@omg.org Subject: Re: Issue 3417 - TransactionalObject remnants In-Reply-To: <20000503185608.C13684@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ?:Ud93S""!pEd!!0;h!! On Wed, 3 May 2000, Blake Biesecker wrote: > Revised Text: > In section 10.3.10, under the heading "Design Rationale", change > > to: > > "In CORBA 2.3, an object declared its ability to support a ^^^^^^^^^ > shared transaction by inheriting from an empty interface > called TransactionalObject. Such an object always received > a shared transaction if one was active, but did not receive > one when there was no active transaction. This behavior is > more accurately described as allowing a shared transaction, > since such an object may or may not receive a shared transaction. > CORBA 2.3 and before did not provide a mechanism to require ^^^^^^^^^ > a shared transaction at invocation time since an object > which did not inherit from the TransactionalObject interface > was not able to receive a shared transaction, even when one was > active. This behavior produces the following two by two matrix > of possible choices for shared transaction support: " Should the highlighted bits be "OTS 1.0 and OTS 1.1"? That's because TransactionalObject has nothing to do with CORBA 2.x, really, but is determined by the OTS IDL? Cheers, Michi. Date: Wed, 3 May 2000 19:08:04 -0700 From: Blake Biesecker To: Michi Henning Cc: ots-rtf@omg.org Subject: Re: Issue 3417 - TransactionalObject remnants Message-ID: <20000503190804.F13672@gemstone.com> References: <20000503185608.C13684@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from michi@ooc.com.au on Thu, May 04, 2000 at 12:02:42PM +1000 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: Q9?e9]JL!!J,@e9enXd9 That makes sense to me. I'll change it. Blake On Thu, May 04, 2000 at 12:02:42PM +1000, Michi Henning wrote: > On Wed, 3 May 2000, Blake Biesecker wrote: > > > Revised Text: > > In section 10.3.10, under the heading "Design Rationale", change > > > > to: > > > > "In CORBA 2.3, an object declared its ability to support a > ^^^^^^^^^ > > shared transaction by inheriting from an empty interface > > called TransactionalObject. Such an object always received > > a shared transaction if one was active, but did not receive > > one when there was no active transaction. This behavior is > > more accurately described as allowing a shared transaction, > > since such an object may or may not receive a shared transaction. > > CORBA 2.3 and before did not provide a mechanism to require > ^^^^^^^^^ > > a shared transaction at invocation time since an object > > which did not inherit from the TransactionalObject interface > > was not able to receive a shared transaction, even when one was > > active. This behavior produces the following two by two matrix > > of possible choices for shared transaction support: " > > Should the highlighted bits be "OTS 1.0 and OTS 1.1"? That's because > TransactionalObject has nothing to do with CORBA 2.x, really, but is > determined by the OTS IDL? > > Cheers, > > Michi. > From: "Mark Little" To: "Michi Henning" , "Blake Biesecker" Cc: References: Subject: Re: Issue 3417 - TransactionalObject remnants Date: Thu, 4 May 2000 09:25:11 +0100 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: ]\;e9%<)!!dQmd9@]V!! ----- Original Message ----- > Should the highlighted bits be "OTS 1.0 and OTS 1.1"? That's because > TransactionalObject has nothing to do with CORBA 2.x, really, but is > determined by the OTS IDL? Agreed. If these changes were made I'd go with the text. 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 Date: Thu, 4 May 2000 14:55:00 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: Issue 3417 - updated proposal - TransactionalObject remnants Message-ID: <20000504145500.A18169@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: ILk!!5gE!!E&5e9h*Td9 Here is the proposal for 3417 with the references to CORBA 2.3 changed to "OTS 1.0 and OTS 1.1". Blake Issue 3417: TransactionalObject remnants (ots-rtf) Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: On page 10-35 of ptc/99-10-07, the text talks about TransactionalObject at the bottom of the page. However, TransactionalObject is deleted at the top of the page, so the two edits don't go together. Also, near the bottom of the page, we have: "In CORBA today, an object declares..." This will be completely meaningless in two years' time. If anything, such things must be expressed in terms of version numbers for the spec. Resolution: Phrases like "CORBA today" will be changes to "CORBA 2.3". TransactionalObject will be briefly explained in the passage mentioned in the summary so that it can be understood by those unfamiliar with CORBA 2.3. Revised Text: In section 10.3.10, under the heading "Design Rationale", change the second paragraph from: "In CORBA today, an object declares its ability to support a shared transaction by inheriting from the TransactionalObject interface. Such an object will always receive a shared transaction if one is active, but will not receive one when there is no active transaction. This behavior is more accurately described as allowing a shared transaction, since the object may or may not receive a shared transaction. Today s CORBA does not provide a mechanism to require a shared transaction at invocation time since an object which does not inherit from TransactionalObject may not receive a shared transaction, even when one is active. This produces the following two by two matrix of possible choices for shared transaction support: " to: "In OTS 1.0 and OTS 1.1, an object declared its ability to support a shared transaction by inheriting from an empty interface called TransactionalObject. Such an object always received a shared transaction if one was active, but did not receive one when there was no active transaction. This behavior is more accurately described as allowing a shared transaction, since such an object may or may not receive a shared transaction. OTS 1.0 and OTS 1.1 did not provide a mechanism to require a shared transaction at invocation time since an object which did not inherit from the TransactionalObject interface was not able to receive a shared transaction, even when one was active. This behavior produces the following two by two matrix of possible choices for shared transaction support: " Actions taken: March 14, 2000: received issue From: "Mark Little" To: "Blake Biesecker" , References: <20000504145500.A18169@gemstone.com> Subject: Re: Issue 3417 - updated proposal - TransactionalObject remnants Date: Fri, 5 May 2000 09:09:12 +0100 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: S"!!!d_Ld9c-Td99";e9 ----- Original Message ----- > "In OTS 1.0 and OTS 1.1, an object declared its ability to > support a shared transaction by inheriting from an empty > interface called TransactionalObject. Such an object always > received a shared transaction if one was active, but did not > receive one when there was no active transaction. This behavior > is more accurately described as allowing a shared transaction, > since such an object may or may not receive a shared transaction. > OTS 1.0 and OTS 1.1 did not provide a mechanism to require a > shared transaction at invocation time since an object which > did not inherit from the TransactionalObject interface was > not able to receive a shared transaction, even when one was > active. Actually this isn't quite true. The OTS 1.0 and 1.1 specifications left it up to the implementation to decide whether or not to propagate a transaction context if the destination was not derived from TO. (10.2.2, page 10-13) Are you now proposing we change the specification to say, in retrospect, that if you're not derived from TO you don't get the context, even if there is one? Isn't that a different issue? > This behavior produces the following two by two matrix > of possible choices for shared transaction support: " > Actions taken: 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: "Bernard Normier" To: "Mark Little" , "Blake Biesecker" , References: <20000504145500.A18169@gemstone.com> <00cc01bfb669$32fb6220$6e96f080@ncl.ac.uk> Subject: Re: Issue 3417 - updated proposal - TransactionalObject remnants Date: Fri, 5 May 2000 12:00:43 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text X-UIDL: nf"!!]@m!!hVNe9]D:e9 Paragraph 10.2.2 on page 10-13 of the Transaction Service 1.1 describes what's going on the the server-side, and not OTS clients responsabilities. I think that saying that "if you're not derived from TO you don't get the context" would go a little bit further than OTS 1.1. OTS 1.1 actually says "if you're not derived from TO, even if you get a context, you must not use it". Receiver::received_request (on page 10-66) reads: "A request has been received. The PropagationContext defines the transaction making the request. It is associated with the target object _only_ _if_ the target object inherits from the TransactionalObject interface". In other terms, even if some ProgationContext gets propagated to an object that does not derive from TransactionalObject, the server must discard it. Then, why propagate it in the first place? The only reason to propagate blindly is to avoid checking if the target is or is not a TransactionalObject. I think we could (maybe even should) allow such implementation, but I'm opposed to making unconditional propagation the only correct implementation. Cheers, Bernard ----- Original Message ----- From: "Mark Little" To: "Blake Biesecker" ; Sent: Friday, May 05, 2000 4:09 AM Subject: Re: Issue 3417 - updated proposal - TransactionalObject remnants > ----- Original Message ----- > > > "In OTS 1.0 and OTS 1.1, an object declared its ability to > > support a shared transaction by inheriting from an empty > > interface called TransactionalObject. Such an object always > > received a shared transaction if one was active, but did not > > receive one when there was no active transaction. This behavior > > is more accurately described as allowing a shared transaction, > > since such an object may or may not receive a shared transaction. > > OTS 1.0 and OTS 1.1 did not provide a mechanism to require a > > shared transaction at invocation time since an object which > > did not inherit from the TransactionalObject interface was > > not able to receive a shared transaction, even when one was > > active. > > Actually this isn't quite true. The OTS 1.0 and 1.1 specifications >left it > up to the implementation to decide whether or not to propagate a >transaction > context if the destination was not derived from TO. (10.2.2, page >10-13) Are > you now proposing we change the specification to say, in retrospect, >that if > you're not derived from TO you don't get the context, even if there >is one? > Isn't that a different issue? > > > This behavior produces the following two by two matrix > > of possible choices for shared transaction support: " > > Actions taken: > > 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: "Bernard Normier" , "Blake Biesecker" , References: <20000504145500.A18169@gemstone.com> <00cc01bfb669$32fb6220$6e96f080@ncl.ac.uk> <065801bfb6ab$13f772f0$6a85413f@boston.amer.iona.com> Subject: Re: Issue 3417 - updated proposal - TransactionalObject remnants Date: Fri, 5 May 2000 17:26:49 +0100 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: >+0e9;ih!!4S-!!D^[d9 ----- Original Message ----- > Paragraph 10.2.2 on page 10-13 of the Transaction Service 1.1 describes > what's going on the the server-side, and not OTS clients responsabilities. True. However, my point is that, as far as I can remember, the current specification does not say that the context must not be shipped if the destination object is not derived from TO. > > I think that saying that "if you're not derived from TO you don't >get > the context" would go a little bit further than OTS 1.1. Agreed, which was my point. > OTS 1.1 actually says "if you're not derived from TO, even if you > get a context, you must not use it". The text says that the thread's context is "undefined" in this case. > Receiver::received_request (on page 10-66) reads: > "A request has been received. The PropagationContext defines the > transaction making the request. It is associated with the target > object _only_ _if_ the target object inherits from the > TransactionalObject > interface". Yes, but CosTSPortability only gets called if the object is derived from TO. If it's not then I can still propagate the context (albeit through a different mechanism). > In other terms, even if some ProgationContext gets propagated to > an object that does not derive from TransactionalObject, the server > must discard it. Then, why propagate it in the first place? > > The only reason to propagate blindly is to avoid checking if the > target is or is not a TransactionalObject. I think we could (maybe > even should) allow such implementation, but I'm opposed to making > unconditional propagation the only correct implementation. So am I, and that was not what I was saying. I was only drawing attention to the fact that the proposed wording appears, IMHO, to preculed the fact that a transaction context may be propagated regardless of the type of the destination object in the current specification. 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 Date: Fri, 5 May 2000 10:19:50 -0700 From: Blake Biesecker To: Mark Little Cc: ots-rtf@omg.org Subject: Re: Issue 3417 - updated proposal - TransactionalObject remnants Message-ID: <20000505101949.B22493@gemstone.com> References: <20000504145500.A18169@gemstone.com> <00cc01bfb669$32fb6220$6e96f080@ncl.ac.uk> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <00cc01bfb669$32fb6220$6e96f080@ncl.ac.uk>; from M.C.Little@ncl.ac.uk on Fri, May 05, 2000 at 09:09:12AM +0100 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: m2O!!QpB!!$k#!!&gF!! On Fri, May 05, 2000 at 09:09:12AM +0100, Mark Little wrote: > ----- Original Message ----- > > > "In OTS 1.0 and OTS 1.1, an object declared its ability to > > support a shared transaction by inheriting from an empty > > interface called TransactionalObject. Such an object always > > received a shared transaction if one was active, but did not > > receive one when there was no active transaction. This behavior > > is more accurately described as allowing a shared transaction, > > since such an object may or may not receive a shared transaction. > > OTS 1.0 and OTS 1.1 did not provide a mechanism to require a > > shared transaction at invocation time since an object which > > did not inherit from the TransactionalObject interface was > > not able to receive a shared transaction, even when one was > > active. > > Actually this isn't quite true. The OTS 1.0 and 1.1 specifications left it > up to the implementation to decide whether or not to propagate a transaction > context if the destination was not derived from TO. (10.2.2, page 10-13) Are > you now proposing we change the specification to say, in retrospect, that if > you're not derived from TO you don't get the context, even if there is one? > Isn't that a different issue? > My intention was to describe the state of affairs in 10. and 1.1. (This part of the text was added by the messaging changes, and I just based my text on that.) How about this instead: "In OTS 1.0 and OTS 1.1, an object declared its ability to support a shared transaction by inheriting from an empty interface called TransactionalObject. Such an object always received a shared transaction if one was active. This behavior is more accurately described as allowing a shared transaction, since such an object may or may not receive a shared transaction. OTS 1.0 and OTS 1.1 did not provide a mechanism to require a shared transaction at invocation time since an object which did not inherit from the TransactionalObject interface was not able to receive a shared transaction, even when one was active." Blake > > This behavior produces the following two by two matrix > > of possible choices for shared transaction support: " > > Actions taken: > > 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: "Bernard Normier" To: "Mark Little" , "Blake Biesecker" , References: <20000504145500.A18169@gemstone.com> > > <00cc01bfb669$32fb6220$6e96f080@ncl.ac.uk> > > <065801bfb6ab$13f772f0$6a85413f@boston.amer.iona.com> > > <02d901bfb6ae$b69adb70$6e96f080@ncl.ac.uk> Subject: Re: Issue 3417 - updated proposal - TransactionalObject > > remnants Date: Fri, 5 May 2000 13:56:37 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text X-UIDL: kGB!!>:Xd9;Ypd92BBe9 Hi Mark, > > The only reason to propagate blindly is to avoid checking if the > > target is or is not a TransactionalObject. I think we could (maybe > > even should) allow such implementation, but I'm opposed to making > > unconditional propagation the only correct implementation. > > So am I, and that was not what I was saying. I was only drawing > > attention to > the fact that the proposed wording appears, IMHO, to preculed the > > fact that > a transaction context may be propagated regardless of the type of > > the > destination object in the current specification. > Great. I looks like we're in agreement! I don't see how Blake's proposal precludes or seem to preclude this implementation freedom. Could you be more specific? Maybe the spec should actually state that these two kinds of implementation are indeed correct? Thanks, Bernard Date: Fri, 5 May 2000 11:40:16 -0700 From: Blake Biesecker To: Mark Little Cc: ots-rtf@omg.org Subject: Re: Issue 3417 - updated proposal - TransactionalObject remnants Message-ID: <20000505114016.A16417@gemstone.com> References: <20000504145500.A18169@gemstone.com> <00cc01bfb669$32fb6220$6e96f080@ncl.ac.uk> <20000505101949.B22493@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <20000505101949.B22493@gemstone.com>; from blakeb@gemstone.com on Fri, May 05, 2000 at 10:19:50AM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: cY_d9`6l!!/aad97&Ae9 In looking at this closer, I don't think my revised text addresses the issue. (Sorry for the noise.) Just to be clear is it this text that you are objecting to because it suggests that if an object is not derived from TO, it doesn't get the context, even if there is one: OTS 1.0 and OTS 1.1 did not provide a mechanism to require a shared transaction at invocation time since an object which did not inherit from the TransactionalObject interface was not able to receive a shared transaction, even when one was active. Or is it more involved than that? do you object to the entire characterization of this section (the two by two matrix and the rest)? Blake On Fri, May 05, 2000 at 10:19:50AM -0700, Blake Biesecker wrote: > On Fri, May 05, 2000 at 09:09:12AM +0100, Mark Little wrote: > > ----- Original Message ----- > > > > > "In OTS 1.0 and OTS 1.1, an object declared its ability to > > > support a shared transaction by inheriting from an empty > > > interface called TransactionalObject. Such an object always > > > received a shared transaction if one was active, but did not > > > receive one when there was no active transaction. This behavior > > > is more accurately described as allowing a shared transaction, > > > since such an object may or may not receive a shared transaction. > > > OTS 1.0 and OTS 1.1 did not provide a mechanism to require a > > > shared transaction at invocation time since an object which > > > did not inherit from the TransactionalObject interface was > > > not able to receive a shared transaction, even when one was > > > active. > > > > Actually this isn't quite true. The OTS 1.0 and 1.1 specifications left it > > up to the implementation to decide whether or not to propagate a transaction > > context if the destination was not derived from TO. (10.2.2, page 10-13) Are > > you now proposing we change the specification to say, in retrospect, that if > > you're not derived from TO you don't get the context, even if there is one? > > Isn't that a different issue? > > > > My intention was to describe the state of affairs in 10. and 1.1. > (This part of the text was added by the messaging changes, and I > just based my text on that.) > > How about this instead: > > "In OTS 1.0 and OTS 1.1, an object declared its ability to > support a shared transaction by inheriting from an empty > interface called TransactionalObject. Such an object always > received a shared transaction if one was active. This behavior > is more accurately described as allowing a shared transaction, > since such an object may or may not receive a shared transaction. > OTS 1.0 and OTS 1.1 did not provide a mechanism to require a > shared transaction at invocation time since an object which > did not inherit from the TransactionalObject interface was > not able to receive a shared transaction, even when one was > active." > > Blake > > > > > > > This behavior produces the following two by two matrix > > > of possible choices for shared transaction support: " > > > Actions taken: > > > > 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 > > > > Date: Fri, 5 May 2000 11:54:30 -0700 From: Blake Biesecker To: M.C.Little@ncl.ac.uk Cc: ots-rtf@omg.org Subject: Re: Issue 3417 - updated proposal - TransactionalObject remnants Message-ID: <20000505115430.B16432@gemstone.com> References: <20000504145500.A18169@gemstone.com> <00cc01bfb669$32fb6220$6e96f080@ncl.ac.uk> <065801bfb6ab$13f772f0$6a85413f@boston.amer.iona.com> <02d901bfb6ae$b69adb70$6e96f080@ncl.ac.uk> <002801bfb6bb$42761e00$6a85413f@boston.amer.iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <002801bfb6bb$42761e00$6a85413f@boston.amer.iona.com>; from bernard.normier@iona.com on Fri, May 05, 2000 at 01:56:37PM -0400 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: ?/1e9U&I!!V>2e9:',e9 On Fri, May 05, 2000 at 01:56:37PM -0400, Bernard Normier wrote: > Hi Mark, > > > > The only reason to propagate blindly is to avoid checking if the > > > target is or is not a TransactionalObject. I think we could (maybe > > > even should) allow such implementation, but I'm opposed to making > > > unconditional propagation the only correct implementation. > > > > So am I, and that was not what I was saying. I was only drawing attention to > > the fact that the proposed wording appears, IMHO, to preculed the fact that > > a transaction context may be propagated regardless of the type of the > > destination object in the current specification. > > > > Great. I looks like we're in agreement! > I don't see how Blake's proposal precludes or seem to preclude this > implementation freedom. Could you be more specific? > Maybe the spec should actually state that these two kinds of > implementation are indeed correct? > > Thanks, > > Bernard > Mark, I agree that it would help to get details regarding your objections. I agree with you, but I'm not sure just changing the proposed text will be sufficient. What do you think of the matrix in this section? Blake X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 05 May 2000 08:20:07 -0700 To: Michi Henning , Blake Biesecker From: Edward Cobb Subject: Re: Issue 3417 - TransactionalObject remnants Cc: ots-rtf@omg.org In-Reply-To: References: <20000503185608.C13684@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: H!#"!U=6!!09O!!*h9e9 Michi is correct. At 12:02 PM 5/4/00 +1000, Michi Henning wrote: >On Wed, 3 May 2000, Blake Biesecker wrote: > >> Revised Text: >> In section 10.3.10, under the heading "Design Rationale", change >> >> to: >> >> "In CORBA 2.3, an object declared its ability to support a > ^^^^^^^^^ >> shared transaction by inheriting from an empty interface >> called TransactionalObject. Such an object always received >> a shared transaction if one was active, but did not receive >> one when there was no active transaction. This behavior is >> more accurately described as allowing a shared transaction, >> since such an object may or may not receive a shared transaction. >> CORBA 2.3 and before did not provide a mechanism to require > ^^^^^^^^^ >> a shared transaction at invocation time since an object >> which did not inherit from the TransactionalObject interface >> was not able to receive a shared transaction, even when one was >> active. This behavior produces the following two by two matrix >> of possible choices for shared transaction support: " > >Should the highlighted bits be "OTS 1.0 and OTS 1.1"? That's because >TransactionalObject has nothing to do with CORBA 2.x, really, but is >determined by the OTS IDL? > > Cheers, > > Michi. > > > ************************************************************** 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 ************************************************************** X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 05 May 2000 09:02:04 -0700 To: Blake Biesecker , ots-rtf@omg.org From: Edward Cobb Subject: Re: Issue 3417 - updated proposal - TransactionalObject remnants In-Reply-To: <20000504145500.A18169@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: KkK!!@\Ae95$Ie9oNPe9 As I indicated in my previous note, the intent of the OTS 1.1 changes were to always propagate the context when it was present. This was not true in OTS 1.0. At 02:55 PM 5/4/00 -0700, Blake Biesecker wrote: >Here is the proposal for 3417 with the references to >CORBA 2.3 changed to "OTS 1.0 and OTS 1.1". > >Blake > > >Issue 3417: TransactionalObject remnants (ots-rtf) >Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) >Nature: Uncategorized Issue >Severity: >Summary: On page 10-35 of ptc/99-10-07, the text talks about TransactionalObject >at the bottom of the page. However, TransactionalObject is deleted at >the top of the page, so the two edits don't go together. Also, near >the bottom of the page, we have: "In CORBA today, an object declares..." >This will be completely meaningless in two years' time. If anything, >such things must be expressed in terms of version numbers for the spec. >Resolution: Phrases like "CORBA today" will be changes to "CORBA 2.3". >TransactionalObject will be briefly explained in the passage mentioned >in the summary so that it can be understood by those unfamiliar with >CORBA 2.3. > >Revised Text: > >In section 10.3.10, under the heading "Design Rationale", change >the second paragraph > >from: > >"In CORBA today, an object declares its ability to support a >shared transaction by inheriting from the TransactionalObject >interface. Such an object will always receive a shared transaction >if one is active, but will not receive one when there is no active >transaction. This behavior is more accurately described as allowing >a shared transaction, since the object may or may not receive a >shared transaction. Today s CORBA does not provide a mechanism to >require a shared transaction at invocation time since an object >which does not inherit from TransactionalObject may not receive >a shared transaction, even when one is active. This produces the >following two by two matrix of possible choices for shared >transaction support: " > >to: > >"In OTS 1.0 and OTS 1.1, an object declared its ability to >support a shared transaction by inheriting from an empty >interface called TransactionalObject. Such an object always >received a shared transaction if one was active, but did not >receive one when there was no active transaction. This behavior >is more accurately described as allowing a shared transaction, >since such an object may or may not receive a shared transaction. >OTS 1.0 and OTS 1.1 did not provide a mechanism to require a >shared transaction at invocation time since an object which >did not inherit from the TransactionalObject interface was >not able to receive a shared transaction, even when one was >active. This behavior produces the following two by two matrix >of possible choices for shared transaction support: " >Actions taken: > >March 14, 2000: received issue > > ************************************************************** 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 ************************************************************** From: "Mark Little" To: "Blake Biesecker" Cc: References: <20000504145500.A18169@gemstone.com> <00cc01bfb669$32fb6220$6e96f080@ncl.ac.uk> <20000505101949.B22493@gemstone.com> <20000505114016.A16417@gemstone.com> Subject: Re: Issue 3417 - updated proposal - TransactionalObject remnants Date: Mon, 8 May 2000 09:00:11 +0100 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: 9We!!0TI!!8K$e9[N%e9 ----- Original Message ----- > Just to be clear is it this text that you are objecting > to because it suggests that if an object is not derived > from TO, it doesn't get the context, even if there is one: Yes, that's correct. > > OTS 1.0 and OTS 1.1 did not provide a mechanism to require a > shared transaction at invocation time since an object which > did not inherit from the TransactionalObject interface was > not able to receive a shared transaction, even when one was > active. > > Or is it more involved than that? do you object to the > entire characterization of this section (the two by two > matrix and the rest)? No, I have no objections with the rest. My "objection" isn't really that great, it's just that it seems to imply something that was not specified in the 1.0 and 1.1 specifications. How about changing "was not" to "was not required", or stating that it was down to the implementation of the OTS? 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 Date: Mon, 8 May 2000 12:20:14 -0700 From: Blake Biesecker To: Mark Little Cc: ots-rtf@omg.org Subject: Re: Issue 3417 - updated proposal - TransactionalObject remnants Message-ID: <20000508122014.E23171@gemstone.com> References: <20000504145500.A18169@gemstone.com> <00cc01bfb669$32fb6220$6e96f080@ncl.ac.uk> <20000505101949.B22493@gemstone.com> <20000505114016.A16417@gemstone.com> <005501bfb8c3$71b6c480$6e96f080@ncl.ac.uk> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <005501bfb8c3$71b6c480$6e96f080@ncl.ac.uk>; from M.C.Little@ncl.ac.uk on Mon, May 08, 2000 at 09:00:11AM +0100 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: "jY!!UNE!!L"!"!4[[d9 On Mon, May 08, 2000 at 09:00:11AM +0100, Mark Little wrote: > > ----- Original Message ----- > > > Just to be clear is it this text that you are objecting > > to because it suggests that if an object is not derived > > from TO, it doesn't get the context, even if there is one: > > Yes, that's correct. > > > > > OTS 1.0 and OTS 1.1 did not provide a mechanism to require a > > shared transaction at invocation time since an object which > > did not inherit from the TransactionalObject interface was > > not able to receive a shared transaction, even when one was > > active. > > > > Or is it more involved than that? do you object to the > > entire characterization of this section (the two by two > > matrix and the rest)? > > No, I have no objections with the rest. My "objection" isn't really that > great, it's just that it seems to imply something that was not specified in > the 1.0 and 1.1 specifications. How about changing "was not" to "was not > required", or stating that it was down to the implementation of the OTS? > > Mark. > OK, sounds good to me. I'm planning on going with this wording: "In OTS 1.0 and OTS 1.1, an object declared its ability to support a shared transaction by inheriting from an empty interface called TransactionalObject. Such an object always received a shared transaction if one was active, but did not receive one when there was no active transaction. This behavior is more accurately described as allowing a shared transaction, since such an object may or may not receive a shared transaction. OTS 1.0 and OTS 1.1 did not provide a mechanism to require a shared transaction at invocation time since an object which did not inherit from the TransactionalObject interface was not required to receive a shared transaction, even when one was active. This behavior produces the following two by two matrix of possible choices for shared transaction support: " Blake From: "Mark Little" To: "Blake Biesecker" Cc: References: <20000504145500.A18169@gemstone.com> <00cc01bfb669$32fb6220$6e96f080@ncl.ac.uk> <20000505101949.B22493@gemstone.com> <20000505114016.A16417@gemstone.com> <005501bfb8c3$71b6c480$6e96f080@ncl.ac.uk> <20000508122014.E23171@gemstone.com> Subject: Re: Issue 3417 - updated proposal - TransactionalObject remnants Date: Tue, 9 May 2000 08:58:36 +0100 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: O,Y!!W3dd9!5F!!L#~!! ----- Original Message ----- > "In OTS 1.0 and OTS 1.1, an object declared its ability to > support a shared transaction by inheriting from an empty > interface called TransactionalObject. Such an object always > received a shared transaction if one was active, but did not > receive one when there was no active transaction. This behavior > is more accurately described as allowing a shared transaction, > since such an object may or may not receive a shared transaction. > OTS 1.0 and OTS 1.1 did not provide a mechanism to require a > shared transaction at invocation time since an object which > did not inherit from the TransactionalObject interface was > not required to receive a shared transaction, even when one was > active. This behavior produces the following two by two matrix > of possible choices for shared transaction support: " Reads fine to me. 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