Issue 2930: IDL transparency of OTS (ots-rtf) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi@triodia.com) Nature: Uncategorized Issue Severity: Summary: The spec seems to make a number of inconsistent and conflicting claims about transaction propagation. The spec says: Page 10-5: The Transaction Service permits an interface to have both transactional and nontransactional implementations. No IDL extensions are introduced to specify whether or not an operation has transactional behavior. Transactional behavior can be a quality of service that differs in different implementations. I believe that this passage is simply wrong, considering the words elsewhere: Resolution: Issue resolved with changes made by Messaging Revised Text: Actions taken: October 11, 1999: received issue January 16, 2001: closed issue Discussion: Since the ambiguities mentioned in this issue's summary and in its archives are addressed by the changes made to the OTS specification by the Messaging specification, this issue can be closed without action. End of Annotations:===== Date: Mon, 11 Oct 1999 13:29:12 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: issues@omg.org Subject: ots-rtf: IDL transparency of OTS Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: TFK!!j)^!!i%:e9J)/!! The spec seems to make a number of inconsistent and conflicting claims about transaction propagation. The spec says: Page 10-5: The Transaction Service permits an interface to have both transactional and nontransactional implementations. No IDL extensions are introduced to specify whether or not an operation has transactional behavior. Transactional behavior can be a quality of service that differs in different implementations. I believe that this passage is simply wrong, considering the words elsewhere: Page 10-13: The object adapter is not required to initialize the transaction context of every request handler. It is required to initialize the transaction context only if the interface supported by the target object is derived from the TransactionalObject interface. Otherwise, the initial transaction context of the thread is undefined. This contradicts the first quote -- -- inheritance from TransactionalObject clearly affects the IDL. Page 10-14: An application can propagate a transaction context by passing the Control as an explicit request parameter. Again, this is in conflict with the text on page 10-5, which claims that no IDL extensions are required, whereas the above two passages make it clear that either the target object must inherit from TransactionalObject, or the Control object must be passed as an additional IDL parameter. Either approach requires IDL changes. Page 10-11: Avoidance of OMG IDL interface variants. The Transaction Service allows a single interface to be supported by both transactional and non-transactional implementations. This approach avoids a potential "combinatorial explosion" of interface variants that differ only in their transactional characteristics. For example, the existing Object Service interfaces can support transactional behavior without change. This claim, in light of the other passages, would appear to be false. For example, how would I make a transactional OMG Naming Service? None of the interfaces inherit from TransactionalObject, so implicit transaction propagation is not guaranteed. On the other hand, none of the operations permit passing a Control parameter, so explicit transaction propagation is impossible. 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 From: Jeffrey Mischkinsky Message-Id: <199910110541.WAA26314@wheel.dcn.davis.ca.us> Subject: Re: ots-rtf: IDL transparency of OTS To: michi@ooc.com.au (Michi Henning) Date: Sun, 10 Oct 1999 22:41:10 -0700 (PDT) Cc: issues@omg.org In-Reply-To: from "Michi Henning" at Oct 11, 99 01:29:12 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text X-UIDL: p([d9+@]!!R/Ce9Q+,!! Michi, Aren't a lot of these issues now moot, since with the adoption of the messaging spec, the whole notion of the T.O. was deprecated, and replaced with policies specified in the IOR? Ed had been talking about updating the spec to reflect these adoptions. jeff 'Michi Henning' writes: > > The spec seems to make a number of inconsistent and conflicting > claims > about transaction propagation. > > The spec says: > > Page 10-5: > > The Transaction Service permits an interface to have both > transactional and nontransactional implementations. No IDL > extensions are introduced to specify whether or not an > operation > has transactional behavior. Transactional behavior can be a > quality of service that differs in different implementations. > > I believe that this passage is simply wrong, considering the words > elsewhere: > > Page 10-13: > > The object adapter is not required to initialize the > transaction > context of every request handler. It is required to initialize > the transaction context only if the interface supported by the > target object is derived from the TransactionalObject > interface. > Otherwise, the initial transaction context of the thread is > undefined. > > This contradicts the first quote -- -- inheritance from > TransactionalObject > clearly affects the IDL. > > Page 10-14: > > An application can propagate a transaction context by passing > the Control as an explicit request parameter. > > Again, this is in conflict with the text on page 10-5, which claims > that > no IDL extensions are required, whereas the above two passages make > it > clear that either the target object must inherit from > TransactionalObject, > or the Control object must be passed as an additional IDL parameter. > Either approach requires IDL changes. > > Page 10-11: > > Avoidance of OMG IDL interface variants. > > The Transaction Service allows a single interface to be > supported > by both transactional and non-transactional implementations. > This approach avoids a potential "combinatorial explosion" of > interface variants that differ only in their transactional > characteristics. For example, the existing Object Service > interfaces can support transactional behavior without change. > > This claim, in light of the other passages, would appear to be > false. > For example, how would I make a transactional OMG Naming Service? > None of the interfaces inherit from TransactionalObject, so implicit > transaction propagation is not guaranteed. On the other hand, none > of the operations permit passing a Control parameter, so explicit > transaction > propagation is impossible. > > 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 > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Date: Mon, 11 Oct 1999 15:44:53 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: Jeffrey Mischkinsky cc: issues@omg.org Subject: Re: ots-rtf: IDL transparency of OTS In-Reply-To: <199910110541.WAA26314@wheel.dcn.davis.ca.us> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: -?^!!)~6!!L,R!!O[Ae9 On Sun, 10 Oct 1999, Jeffrey Mischkinsky wrote: > Michi, > Aren't a lot of these issues now moot, since with the adoption of > the messaging spec, the whole notion of the T.O. was deprecated, > and replaced with policies specified in the IOR? > > Ed had been talking about updating the spec to reflect these > adoptions. You may well be right. Unfortunately, that doesn't help me if it isn't written down anywhere. Do you know of a more up-to-date version of the OTS document? 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