Issue 2932: ots-rtf: non-transactional objects (ots-rtf) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi@triodia.com) Nature: Uncategorized Issue Severity: Summary: The spec says that a transactional object can call into a non-transactional one (page 10-5). Fine. But it never says what should happen in such a case. Resolution: All this was clarified by the resolution to issue #3245. No change required Revised Text: Actions taken: October 11, 1999: received issue May 13, 2002: closed issue Discussion: End of Annotations:===== Date: Mon, 11 Oct 1999 14:39:11 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: issues@omg.org Subject: ots-rtf: non-transactional objects Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The spec says that a transactional object can call into a non-transactional one (page 10-5). Fine. But it never says what should happen in such a case. Seeing that the non-transactional object will (probably) not receive a transaction context, if the non-transactional object itself calls another transactional object, that nested call will have to happen in another transaction: OTS-aware obj 1 calls --> non-OTS-aware obj calls --> OTS-aware obj 2 Now, if OTS-aware obj 2 makes a callback to OTS-aware obj 1, we will deadlock because the callback will be in a different transaction (if obj 2 starts a new transaction), or it will fail with an exception, (if obj 2 doesn't start a new transaction). OTS-aware obj 1 calls --> non-OTS-aware obj calls --> OTS-aware obj 2 ^ | | | +---------------------------------------------------+ What I don't understand is this: why not simply force an ORB to propagate the transaction context *always* on all calls, instead of using this idea of inheriting from TransactionalObject? This would seem to solve a lot of problems to me. In particular, transaction context propagation would become truly transparent. (Right now, it is undefined as to whether an ORB passes the transaction context on if a call is made to a non-transactional object, so I can't rely on anything. In addition, transaction context propagation is *never* transparent, because it requires inheritance from TransactionalObject or passing an explicit Control parameter.) 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: "Bruce Schuchardt" To: "Michi Henning" , References: Subject: Re: ots-rtf: non-transactional objects Date: Mon, 11 Oct 1999 11:07:41 -0700 Organization: GemStone Systems, Inc 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" Isn't this covered in the Messaging spec? Propagation of transaction contexts is spelled out in much more detail there than in the 1.1 OTS spec. ----- Original Message ----- From: Michi Henning To: Sent: Sunday, October 10, 1999 9:39 PM Subject: ots-rtf: non-transactional objects > > The spec says that a transactional object can call into a non-transactional > one (page 10-5). Fine. But it never says what should happen in such > a case. > > Seeing that the non-transactional object will (probably) not receive > a > transaction context, if the non-transactional object itself calls > another > transactional object, that nested call will have to happen in > another > transaction: > > OTS-aware obj 1 calls --> non-OTS-aware obj calls --> OTS-aware obj > 2 > > Now, if OTS-aware obj 2 makes a callback to OTS-aware obj 1, we will deadlock > because the callback will be in a different transaction (if obj 2 > starts > a new transaction), or it will fail with an exception, (if obj 2 > doesn't > start a new transaction). > > OTS-aware obj 1 calls --> non-OTS-aware obj calls --> > OTS-aware obj 2 > ^ > | > | > | > > +---------------------------------------------------+ > > What I don't understand is this: why not simply force an ORB to > propagate > the transaction context *always* on all calls, instead of using this > idea of inheriting from TransactionalObject? This would seem to > solve a > lot of problems to me. In particular, transaction context > propagation > would become truly transparent. (Right now, it is undefined as to > whether > an ORB passes the transaction context on if a call is made to a > non-transactional object, so I can't rely on anything. In addition, > transaction context propagation is *never* transparent, because it requires > inheritance from TransactionalObject or passing an explicit Control parameter.) > > 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 > > Date: Tue, 12 Oct 1999 05:54:12 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: Bruce Schuchardt cc: issues@omg.org Subject: Re: ots-rtf: non-transactional objects In-Reply-To: <011b01bf1415$c358aae0$bf8210b0@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 11 Oct 1999, Bruce Schuchardt wrote: > Isn't this covered in the Messaging spec? Propagation of transaction > contexts is spelled out in much more detail there than in the 1.1 OTS spec. Yes, there is some more stuff there. PSS and components also make some changes Ed Cobb tells me. We badly need an updated 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 Date: Mon, 11 Oct 1999 13:25:06 -0700 From: Bruce Schuchardt To: Michi Henning Cc: issues@omg.org Subject: Re: ots-rtf: non-transactional objects Message-ID: <19991011132506.A22117@gemstone.com> References: <011b01bf1415$c358aae0$bf8210b0@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 0.95.6us In-Reply-To: ; from Michi Henning on Tue, Oct 12, 1999 at 05:54:12AM +1000 Content-Type: text/plain; charset=us-ascii Oh, yes, the "ots lite" destrictions in PSS - I forgot. You're right, it's time to update the OTS spec. I don't think we should wait for the structured-transactions work to complete. On Tue, Oct 12, 1999 at 05:54:12AM +1000, Michi Henning wrote: > On Mon, 11 Oct 1999, Bruce Schuchardt wrote: > > > Isn't this covered in the Messaging spec? Propagation of > transaction > > contexts is spelled out in much more detail there than in the 1.1 > OTS spec. > > Yes, there is some more stuff there. PSS and components also make > some changes > Ed Cobb tells me. We badly need an updated 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 > Reply-To: From: "Eric Newcomer" To: "'Blake Biesecker'" , Subject: RE: Issue 2932: ots-rtf: non-transactional objects Date: Wed, 9 Feb 2000 13:25:30 -0500 Message-ID: <003501bf732b$0c73b200$b185413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20000208180215.I430@gemstone.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: OmKd9?!Ce98ZP!!C^od9 Hopefully this is settled by not passing context unless the object is transactional. -----Original Message----- From: Blake Biesecker [mailto:blakeb@gemstone.com] Sent: Tuesday, February 08, 2000 9:02 PM To: ots-rtf@omg.org Subject: Issue 2932: ots-rtf: non-transactional objects (first message didn't have a proper subject line ...) This issue is similar to 2933. It is resolved by the Messaging spec. (Michi please let me know if you feel that this issue is not adequately addressed there.) If Messaging is not part of 2.3, then we need to decide how much effort we should put into fixing problems in the 2.3 spec that are fixed in the 3.0 spec ... But the first question to answer is what level is Messaging at? Anybody have a definitive answer on this? Blake Issue 2932: ots-rtf: non-transactional objects (ots-rtf) Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: The spec says that a transactional object can call into a non-transactional one (page 10-5). Fine. But it never says what should happen in such a case. Resolution: Revised Text: Actions taken: October 11, 1999: received issue Discussion: End of Annotations:===== Date: Mon, 11 Oct 1999 14:39:11 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: issues@omg.org Subject: ots-rtf: non-transactional objects Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The spec says that a transactional object can call into a non-transactional one (page 10-5). Fine. But it never says what should happen in such a case. Seeing that the non-transactional object will (probably) not receive a transaction context, if the non-transactional object itself calls another transactional object, that nested call will have to happen in another transaction: OTS-aware obj 1 calls --> non-OTS-aware obj calls --> OTS-aware obj 2 Now, if OTS-aware obj 2 makes a callback to OTS-aware obj 1, we will deadlock because the callback will be in a different transaction (if obj 2 starts a new transaction), or it will fail with an exception, (if obj 2 doesn't start a new transaction). OTS-aware obj 1 calls --> non-OTS-aware obj calls --> OTS-aware obj 2 ^ | | | +---------------------------------------------------+ What I don't understand is this: why not simply force an ORB to propagate the transaction context *always* on all calls, instead of using this idea of inheriting from TransactionalObject? This would seem to solve a lot of problems to me. In particular, transaction context propagation would become truly transparent. (Right now, it is undefined as to whether an ORB passes the transaction context on if a call is made to a non-transactional object, so I can't rely on anything. In addition, transaction context propagation is *never* transparent, because it requires inheritance from TransactionalObject or passing an explicit Control parameter.) 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: "Bruce Schuchardt" To: "Michi Henning" , References: Subject: Re: ots-rtf: non-transactional objects Date: Mon, 11 Oct 1999 11:07:41 -0700 Organization: GemStone Systems, Inc 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" Isn't this covered in the Messaging spec? Propagation of transaction contexts is spelled out in much more detail there than in the 1.1 OTS spec. ----- Original Message ----- From: Michi Henning To: Sent: Sunday, October 10, 1999 9:39 PM Subject: ots-rtf: non-transactional objects > > The spec says that a transactional object can call into a non-transactional > one (page 10-5). Fine. But it never says what should happen in such > a case. > > Seeing that the non-transactional object will (probably) not receive > a > transaction context, if the non-transactional object itself calls > another > transactional object, that nested call will have to happen in > another > transaction: > > OTS-aware obj 1 calls --> non-OTS-aware obj calls --> OTS-aware obj > 2 > > Now, if OTS-aware obj 2 makes a callback to OTS-aware obj 1, we will deadlock > because the callback will be in a different transaction (if obj 2 > starts > a new transaction), or it will fail with an exception, (if obj 2 > doesn't > start a new transaction). > > OTS-aware obj 1 calls --> non-OTS-aware obj calls --> > OTS-aware obj 2 > ^ > | > | > | > > +---------------------------------------------------+ > > What I don't understand is this: why not simply force an ORB to > propagate > the transaction context *always* on all calls, instead of using this > idea of inheriting from TransactionalObject? This would seem to > solve a > lot of problems to me. In particular, transaction context > propagation > would become truly transparent. (Right now, it is undefined as to > whether > an ORB passes the transaction context on if a call is made to a > non-transactional object, so I can't rely on anything. In addition, > transaction context propagation is *never* transparent, because it requires > inheritance from TransactionalObject or passing an explicit Control parameter.) > > 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 > > Date: Tue, 12 Oct 1999 05:54:12 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: Bruce Schuchardt cc: issues@omg.org Subject: Re: ots-rtf: non-transactional objects In-Reply-To: <011b01bf1415$c358aae0$bf8210b0@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 11 Oct 1999, Bruce Schuchardt wrote: > Isn't this covered in the Messaging spec? Propagation of transaction > contexts is spelled out in much more detail there than in the 1.1 OTS spec. Yes, there is some more stuff there. PSS and components also make some changes Ed Cobb tells me. We badly need an updated 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 Date: Mon, 11 Oct 1999 13:25:06 -0700 From: Bruce Schuchardt To: Michi Henning Cc: issues@omg.org Subject: Re: ots-rtf: non-transactional objects Message-ID: <19991011132506.A22117@gemstone.com> References: <011b01bf1415$c358aae0$bf8210b0@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 0.95.6us In-Reply-To: ; from Michi Henning on Tue, Oct 12, 1999 at 05:54:12AM +1000 Content-Type: text/plain; charset=us-ascii Oh, yes, the "ots lite" destrictions in PSS - I forgot. You're right, it's time to update the OTS spec. I don't think we should wait for the structured-transactions work to complete. On Tue, Oct 12, 1999 at 05:54:12AM +1000, Michi Henning wrote: > On Mon, 11 Oct 1999, Bruce Schuchardt wrote: > > > Isn't this covered in the Messaging spec? Propagation of > transaction > > contexts is spelled out in much more detail there than in the 1.1 > OTS spec. > > Yes, there is some more stuff there. PSS and components also make > some changes > Ed Cobb tells me. We badly need an updated 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 > Date: Tue, 8 Feb 2000 17:41:56 -0800 From: Blake Biesecker To: ots-rtf@omg.org Subject: I Message-ID: <20000208174156.G430@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: KO1e9d~&e9NZ6!!pIld9 This issue is similar to 2933. It is resolved by the Messaging spec. (Michi please let me know if you feel that this issue is not adequately addressed there.) If Messaging is not part of 2.3, then we need to decide how much effort we should put into fixing problems in the 2.3 spec that are fixed in the 3.0 spec ... But the first question to answer is what level is Messaging at? Anybody have a definitive answer on this? Blake Issue 2932: ots-rtf: non-transactional objects (ots-rtf) Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: The spec says that a transactional object can call into a non-transactional one (page 10-5). Fine. But it never says what should happen in such a case. Resolution: Revised Text: Actions taken: October 11, 1999: received issue Discussion: End of Annotations:===== Date: Mon, 11 Oct 1999 14:39:11 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: issues@omg.org Subject: ots-rtf: non-transactional objects Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The spec says that a transactional object can call into a non-transactional one (page 10-5). Fine. But it never says what should happen in such a case. Seeing that the non-transactional object will (probably) not receive a transaction context, if the non-transactional object itself calls another transactional object, that nested call will have to happen in another transaction: OTS-aware obj 1 calls --> non-OTS-aware obj calls --> OTS-aware obj 2 Now, if OTS-aware obj 2 makes a callback to OTS-aware obj 1, we will deadlock because the callback will be in a different transaction (if obj 2 starts a new transaction), or it will fail with an exception, (if obj 2 doesn't start a new transaction). OTS-aware obj 1 calls --> non-OTS-aware obj calls --> OTS-aware obj 2 ^ | | | +---------------------------------------------------+ What I don't understand is this: why not simply force an ORB to propagate the transaction context *always* on all calls, instead of using this idea of inheriting from TransactionalObject? This would seem to solve a lot of problems to me. In particular, transaction context propagation would become truly transparent. (Right now, it is undefined as to whether an ORB passes the transaction context on if a call is made to a non-transactional object, so I can't rely on anything. In addition, transaction context propagation is *never* transparent, because it requires inheritance from TransactionalObject or passing an explicit Control parameter.) 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: "Bruce Schuchardt" To: "Michi Henning" , References: Subject: Re: ots-rtf: non-transactional objects Date: Mon, 11 Oct 1999 11:07:41 -0700 Organization: GemStone Systems, Inc 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" Isn't this covered in the Messaging spec? Propagation of transaction contexts is spelled out in much more detail there than in the 1.1 OTS spec. ----- Original Message ----- From: Michi Henning To: Sent: Sunday, October 10, 1999 9:39 PM Subject: ots-rtf: non-transactional objects > > The spec says that a transactional object can call into a non-transactional > one (page 10-5). Fine. But it never says what should happen in such > a case. > > Seeing that the non-transactional object will (probably) not receive > a > transaction context, if the non-transactional object itself calls > another > transactional object, that nested call will have to happen in > another > transaction: > > OTS-aware obj 1 calls --> non-OTS-aware obj calls --> OTS-aware obj > 2 > > Now, if OTS-aware obj 2 makes a callback to OTS-aware obj 1, we will deadlock > because the callback will be in a different transaction (if obj 2 > starts > a new transaction), or it will fail with an exception, (if obj 2 > doesn't > start a new transaction). > > OTS-aware obj 1 calls --> non-OTS-aware obj calls --> > OTS-aware obj 2 > ^ > | > | > | > > +---------------------------------------------------+ > > What I don't understand is this: why not simply force an ORB to > propagate > the transaction context *always* on all calls, instead of using this > idea of inheriting from TransactionalObject? This would seem to > solve a > lot of problems to me. In particular, transaction context > propagation > would become truly transparent. (Right now, it is undefined as to > whether > an ORB passes the transaction context on if a call is made to a > non-transactional object, so I can't rely on anything. In addition, > transaction context propagation is *never* transparent, because it requires > inheritance from TransactionalObject or passing an explicit Control parameter.) > > 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 > > Date: Tue, 12 Oct 1999 05:54:12 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: Bruce Schuchardt cc: issues@omg.org Subject: Re: ots-rtf: non-transactional objects In-Reply-To: <011b01bf1415$c358aae0$bf8210b0@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 11 Oct 1999, Bruce Schuchardt wrote: > Isn't this covered in the Messaging spec? Propagation of transaction > contexts is spelled out in much more detail there than in the 1.1 OTS spec. Yes, there is some more stuff there. PSS and components also make some changes Ed Cobb tells me. We badly need an updated 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 Date: Mon, 11 Oct 1999 13:25:06 -0700 From: Bruce Schuchardt To: Michi Henning Cc: issues@omg.org Subject: Re: ots-rtf: non-transactional objects Message-ID: <19991011132506.A22117@gemstone.com> References: <011b01bf1415$c358aae0$bf8210b0@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 0.95.6us In-Reply-To: ; from Michi Henning on Tue, Oct 12, 1999 at 05:54:12AM +1000 Content-Type: text/plain; charset=us-ascii Oh, yes, the "ots lite" destrictions in PSS - I forgot. You're right, it's time to update the OTS spec. I don't think we should wait for the structured-transactions work to complete. On Tue, Oct 12, 1999 at 05:54:12AM +1000, Michi Henning wrote: > On Mon, 11 Oct 1999, Bruce Schuchardt wrote: > > > Isn't this covered in the Messaging spec? Propagation of > transaction > > contexts is spelled out in much more detail there than in the 1.1 > OTS spec. > > Yes, there is some more stuff there. PSS and components also make > some changes > Ed Cobb tells me. We badly need an updated 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 > Date: Tue, 8 Feb 2000 17:54:57 -0800 From: Blake Biesecker To: ots-rtf@omg.org Subject: I Message-ID: <20000208175456.H430@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: [+Ee9E`!"![36e9d6J!! At the very least, I think we should remove this section from the spec. If we others think it is important to mention how to find a TransactionFactory, I don't have a problem I have with using resolve_initial_references, although we might want to discuss the need to find more than one TransactionFactory. (So, just allowing resolve_initial_references("TransactionFactory") might not meet needs of all applications.) comments? suggestions? Blake issue archive: ------------------------------- Issue 2934: ots-rtf: TransactionFactory (ots-rtf) Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: Page 10-21: A TransactionFactory is located using the FactoryFinder interface of the life cycle service and not by the resolve_initial_reference operation on the ORB interface defined in "Example Object Adapters" in Chapter 2 of the Common Object Request Broker: Architecture and Specification. There are a number of issues here: 1) The section referred to here no longer exists. 2) The life cycle is not an optional component of CORBA. Yet, it appears that OTS cannot be implemented without the Life Cycle Service. 3) Neither OTS nor the Life Cycle Service make a statement as to how I could obtain the FactoryFinder interface that I need to get the transaction factory. I therefore cannot write portable code. 4) The OTS spec makes no statement as to, once I have obtained a factory finder, what factory name I should provide to the find_factories() operation in order to obtain a reference to the transaction factory, so it is impossible to write portable code. 5) We already have resolve_initial_references to solve initial reference problem. Why use a factory finder for this then? In particular, resolve_initial_references("TransactionCurrent") is already in use to obtain a reference to the Current object, so why have two different mechanism for locating initial objects within the same service? Resolution: Revised Text: Actions taken: October 11, 1999: received issue Discussion: End of Annotations:===== Date: Mon, 11 Oct 1999 14:24:10 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: issues@omg.org Subject: ots-rtf: TransactionFactory Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Page 10-21: A TransactionFactory is located using the FactoryFinder interface of the life cycle service and not by the resolve_initial_reference operation on the ORB interface defined in "Example Object Adapters" in Chapter 2 of the Common Object Request Broker: Architecture and Specification. There are a number of issues here: 1) The section referred to here no longer exists. 2) The life cycle is not an optional component of CORBA. Yet, it appears that OTS cannot be implemented without the Life Cycle Service. 3) Neither OTS nor the Life Cycle Service make a statement as to how I could obtain the FactoryFinder interface that I need to get the transaction factory. I therefore cannot write portable code. 4) The OTS spec makes no statement as to, once I have obtained a factory finder, what factory name I should provide to the find_factories() operation in order to obtain a reference to the transaction factory, so it is impossible to write portable code. 5) We already have resolve_initial_references to solve initial reference problem. Why use a factory finder for this then? In particular, resolve_initial_references("TransactionCurrent") is already in use to obtain a reference to the Current object, so why have two different mechanism for locating initial objects within the same service? 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 Date: Wed, 9 Feb 2000 12:23:38 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: ots-rtf@omg.org Subject: Re: I In-Reply-To: <20000208174156.G430@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: E$i!!EFEe9U#=e9#;6e9 On Tue, 8 Feb 2000, Blake Biesecker wrote: > This issue is similar to 2933. It is resolved by the Messaging > spec. (Michi please let me know if you feel that this issue > is not adequately addressed there.) It looks like it is (well almost). On page 10-37 (in the merged document): When it issues requests on transactional objects, the transaction context associated with the current thread is implicitly propagated to the object. That's wrong as it stands. Whether or not an object is transactional for a particular invocation can vary at run time. It can depend on the operation name or even the parameter values. It follows that the client has no way to figure whether or not a particular object is transactional. Ergo, the only way to deal with this is to require an ORB to unconditionally propagate the transaction context if the client has one. This is particularly important if I call from a client that has a transaction to a non-transactional object, which in turn calls a transactional object. In that case, the original transaction context must be passed through the non-transactional object, otherwise we break transaction propagation in inexplicable and unpredicatable ways. So, I think that we must oblige an ORB to not throw any part of the service context away for chained calls. 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 12:45:30 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: ots-rtf@omg.org Subject: Re: I In-Reply-To: <20000208175456.H430@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Xe1!!:Z^d9cbW!!&A8e9 On Tue, 8 Feb 2000, Blake Biesecker wrote: > At the very least, I think we should remove this section from > the spec. If we others think it is important to mention how > to find a TransactionFactory, I agree. What's in there now is pure fantasy material. > I don't have a problem I have with > using resolve_initial_references, although we might want to > discuss the need to find more than one TransactionFactory. > (So, just allowing resolve_initial_references("TransactionFactory") > might not meet needs of all applications.) > > comments? suggestions? Well, in the past, we have never worried about this either. For example, if I want to use several naming services simultaneously, I have to get all but one using some other means. However, note that with INS, you can use the command line to add new tokens to what is accepted by resolve_initial_references. I think that solves the problem adequately. The easy way out I can see at the moment is to state that resolve_initial_references("TransactionFactory") returns the factory ref. The core spec currently also talks about "TransactionCurrent" as a token for resolve_initial_references. That one causes problems when combined with the above idea of having more than one OTS in a process. That's because there is only one Current (it's a singleton object). However, if I have two OTSs in the same process, this completely falls apart. A call to resolve_initial_references("TransactionCurrent") does not have enough context info to determine which of the two possible Current objects I might mean... The way I see it, OTS was never designed to work with more than one transaction implementation at the same time (and we probably shouldn't try to make it do that). 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 From: Jeffrey Mischkinsky Message-Id: <200002090333.TAA06742@wheel.dcn.davis.ca.us> Subject: Re: I To: michi@ooc.com.au (Michi Henning) Date: Tue, 8 Feb 2000 19:33:23 -0800 (PST) Cc: blakeb@gemstone.com (Blake Biesecker), ots-rtf@omg.org In-Reply-To: from "Michi Henning" at Feb 09, 2000 12:45:30 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: QJK!!e'ad9-o8e9H/?e9 'Michi Henning' writes: > > On Tue, 8 Feb 2000, Blake Biesecker wrote: > > Well, in the past, we have never worried about this either. For > example, > if I want to use several naming services simultaneously, I have to > get > all but one using some other means. However, note that with INS, you > can use the command line to add new tokens to what is accepted by > resolve_initial_references. I think that solves the problem > adequately. > > The easy way out I can see at the moment is to state that > resolve_initial_references("TransactionFactory") returns the factory > ref. > > The core spec currently also talks about "TransactionCurrent" as a > token > for resolve_initial_references. That one causes problems when > combined > with the above idea of having more than one OTS in a process. That's > because there is only one Current (it's a singleton > object). However, > if I have two OTSs in the same process, this completely falls apart. > A call to resolve_initial_references("TransactionCurrent") does not > have enough context info to determine which of the two possible > Current > objects I might mean... > > The way I see it, OTS was never designed to work with more than one > transaction implementation at the same time (and we probably > shouldn't try > to make it do that). I think that's true and I think I agree. I think that was an (implicit) assumption at the time. Ask Ed, he was there "at creation" also. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 From: "Mark Little" To: "Michi Henning" , "Blake Biesecker" Cc: References: Subject: Re: I Date: Wed, 9 Feb 2000 09:38:36 -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: TQTd9U4&e9,1%!!C&0!! ----- Original Message ----- > When it issues requests on transactional objects, the transaction > context associated with the current thread is implicitly > propagated to the object. > > That's wrong as it stands. Whether or not an object is transactional > for > a particular invocation can vary at run time. It can depend on the operation > name or even the parameter values. It follows that the client has no > way to figure whether or not a particular object is transactional. > Ergo, the only way to deal with this is to require an ORB to unconditionally > propagate the transaction context if the client has one. > > This is particularly important if I call from a client that has a > transaction to a non-transactional object, which in turn calls a > transactional object. In that case, the original transaction context > must be passed through the non-transactional object, otherwise we > break transaction propagation in inexplicable and unpredicatable > ways. >From my understanding of the POA and POI this is less of an issue than in the "old" BOA days, but the fact that it breaks location transparency can be a big problem. For example, programmer X decides to try co-locating certain objects to start with. The don't need to be derived from TransactionalObject (I know this has been dropped, but bear with me!) in order to get the transaction context, since it's implicitly associated with the thread of control. However, if he later decides that some objects must be placed in a separate process their signatures must be changed. The obvious solution to this is to force all objects, local and remote, that want the context to be derived from TransactionalObject. There are several problems with this, including the fact that the programmer may not have control over the object through which his transactional object is invoked (in Michi's example the invocation comes through a non-transactional object), his requirements may change for the object over time, and certain operations may be transactional whereas others may not. I believe that with the POA and POI, interceptors must be called even on co-located invocations, so maybe this isn't an issue any more. However, being devil's advocate, always propagating the transaction context implies a performance hit on those objects which don't need it. The size of the context, especially when you're talking about using nested transactions, may be hugh in comparison to the size of the non-transactional message invocation size. So I can see a requirement for being able to say "don't propagate". My current preference to a "solution" is that we tighten up the text (allowing contexts to not be propagated) and essentially warn programmers about the "tx object-to non-tx object-to tx-object" problem. Another option (and I'm not sure how possible this one is) would be to allow an application user/programmer to dynamically specify that contexts must be propagated all of the time - could this be another POA attribute? The default would be to not send the context unless the target is explicitly transactional, but allowing more control to the user. 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: Wed, 9 Feb 2000 20:07:43 +1000 (EST) From: Michi Henning To: Mark Little cc: ots-rtf@omg.org Subject: Re: I In-Reply-To: <089601bf72e1$705749c0$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Z(V!!Z]g!!Re~!!Fhhd9 On Wed, 9 Feb 2000, Mark Little wrote: > > ----- Original Message ----- > > > When it issues requests on transactional objects, the transaction > > context associated with the current thread is implicitly > > propagated to the object. > > > > That's wrong as it stands. Whether or not an object is > transactional for > > a particular invocation can vary at run time. It can depend on the > operation > > name or even the parameter values. It follows that the client has > no > > way to figure whether or not a particular object is transactional. > > Ergo, the only way to deal with this is to require an ORB to > unconditionally > > propagate the transaction context if the client has one. > > > > This is particularly important if I call from a client that has a > > transaction to a non-transactional object, which in turn calls a > > transactional object. In that case, the original transaction > context > > must be passed through the non-transactional object, otherwise we > > break transaction propagation in inexplicable and unpredicatable > ways. > > >From my understanding of the POA and POI this is less of an issue > than in > the "old" BOA days, but the fact that it breaks location > transparency can be > a big problem. For example, programmer X decides to try co-locating > certain > objects to start with. The don't need to be derived from > TransactionalObject > (I know this has been dropped, but bear with me!) in order to get > the > transaction context, since it's implicitly associated with the > thread of > control. However, if he later decides that some objects must be > placed in a > separate process their signatures must be changed. I don't follow the reasoning. Given that TransactionalObject no longer exists, no signature change is necessary. > The obvious solution to > this is to force all objects, local and remote, that want the > context to be > derived from TransactionalObject. There are several problems with > this, > including the fact that the programmer may not have control over the > object > through which his transactional object is invoked (in Michi's > example the > invocation comes through a non-transactional object), his > requirements may > change for the object over time, and certain operations may be > transactional > whereas others may not. Sorry, I don't get it -- as far as I can see, the entire TransactionalObject thing doesn't enter into the discussion. The way things are, *any* object can be transactional or not and you cannot tell from an object's interface whether it is transactional or not. (That's how it should be too, IMO.) It follows that an object can make dynamic decisions as to whether it is transactional based on anything it likes, such as the time of day. That in turn implies that the only way to get transactional behavior (if an object indeed does support transactional behavior) is to send the context unconditionally with every call. > I believe that with the POA and POI, interceptors must be called even on > co-located invocations, so maybe this isn't an issue any more. Yes, interceptors are guaranteed to be called regardless of where the target object is. > However, being devil's advocate, always propagating the transaction context > implies a performance hit on those objects which don't need it. The size of > the context, especially when you're talking about using nested transactions, > may be hugh in comparison to the size of the non-transactional message > invocation size. So I can see a requirement for being able to say "don't > propagate". I don't see this myself. A transaction context will get huge only if we have very deeply nested transactions. I cannot see a nesting level of more than 4 or 5 transactions even in the most complex application. Yes, the context adds to the cost of an invocation, especially if the parameter values are small. However, compared to the cost of going on the wire in the first place, that cost is almost impossible to notic. Try it some time -- the cost of a call goes up significanly only once you reach a few hundred bytes in size; up to that point, cost is dominated by latency, not bandwidth (unless you are using very slow links). > My current preference to a "solution" is that we tighten up the text > (allowing contexts to not be propagated) and essentially warn > programmers > about the "tx object-to non-tx object-to tx-object" problem. I am utterly and dead-set against this. It would mean that I cannot have any guarantee whatsoever about sane behavior. How would I tell under what circumstances a context will or won't be propagated? And, if I have the bad luck of calling into a transactional object (which I do not control) which in turn calls a non-transactional object (without my knowledge) which in turn calls one of the objects I currently have in the transaction, I get inexplicable (and unfixable) deadlocks. This isn't sane behavior. > Another option > (and I'm not sure how possible this one is) would be to allow an > application > user/programmer to dynamically specify that contexts must be > propagated all > of the time - could this be another POA attribute? It can't be a POA attribute because the decision as to whether to send a context must be made on the client side. > The default would be to > not send the context unless the target is explicitly transactional, > but > allowing more control to the user. There is *no* way to find out whether the target is transactional. It may be transactional on every second Tuesday only, and non-transactional the rest of the time. In turn, this means that you cannot even make this part of the profile information (or some other part) of the object's IOR. However, there is no problem. If, as an application programmer, I want to be sure that a particular call is sent non-transactionally (is that a word? ;-), I can simply call suspend(), make the call, and call resume(). So, I think we must force propagation of the context regardless of the destination of a call, and we must force non-transactional object to pass that context on if they make further calls. That's simply the cost of using transactions. If I don't want the cost, I shouldn't be using transactions (or call suspend). I can't have the cake and it it too... 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 From: "Mark Little" To: "Michi Henning" Cc: References: Subject: Re: I Date: Wed, 9 Feb 2000 10:31:23 -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: 3ZNe9I--e9ko6e9CQ#e9 ----- Original Message ----- > I don't follow the reasoning. Given that TransactionalObject no longer exists, > no signature change is necessary. I may not have been clear on this: it was meant only from an historical POV to show the problems that may (currently) exist with OTS implementations. > Sorry, I don't get it -- as far as I can see, the entire TransactionalObject > thing doesn't enter into the discussion. The way things are, *any* object > can be transactional or not and you cannot tell from an object's interface > whether it is transactional or not. (That's how it should be too, IMO.) Agreed - no signature changes should be required. However, it's my understanding that once the transactional POA attribute is added your problem will (almost) go away: the creator of the object will be responsible for ensuring it resides with an appropriate POA. > It follows that an object can make dynamic decisions as to whether it > is transactional based on anything it likes, such as the time of day. > That in turn implies that the only way to get transactional behavior > (if an object indeed does support transactional behavior) is to send > the context unconditionally with every call. >From a purist POV we don't have an argument here. However, as I said I can see why not propagating is required, and I thought that because that requirement was important was one reason why the POA attribute was being added to *replace* TransactionalObject. > I don't see this myself. A transaction context will get huge only if > we have very deeply nested transactions. I cannot see a nesting > level > of more than 4 or 5 transactions even in the most complex > application. You're placing restrictions on the types of applications that can be performant then? So you'd also like to see some constraint on the number of nested transactions? I don't think so. I can have as deeply nested an invocation as I want in CORBA, and lets say that at each object my invocation passes through I get a new nested transaction started. It's really easy to get deeply nested transactions. Just because you can't see it doesn't mean it won't/can't happen. > Yes, the context adds to the cost of an invocation, especially if the > parameter values are small. However, compared to the cost of going > on the wire in the first place, that cost is almost impossible to notic. > Try it some time -- the cost of a call goes up significanly only once > you reach a few hundred bytes in size; up to that point, cost is dominated > by latency, not bandwidth (unless you are using very slow links). In the past I have tried it with pre-CORBA RPCs and once you start fragmenting the message buffer (e.g., 1400+ bytes on ethernet) the cost goes up. Since the transaction context contains object references (Coordinators, and possible Terminators, + implementation specific data), the context size even with "only" 4 levels of nesting could quickly go over this. > > > My current preference to a "solution" is that we tighten up the > text > > (allowing contexts to not be propagated) and essentially warn programmers > > about the "tx object-to non-tx object-to tx-object" problem. > > I am utterly and dead-set against this. It would mean that I cannot > have > any guarantee whatsoever about sane behavior. How would I tell under > what circumstances a context will or won't be propagated? You have the POA attribute in the receiver! > And, if I have > the bad luck of calling into a transactional object (which I do not control) > which in turn calls a non-transactional object (without my > knowledge) > which in turn calls one of the objects I currently have in the transaction, > I get inexplicable (and unfixable) deadlocks. This isn't sane > behavior. That's another matter, and comes back to my original "historical" point about the TransactionalObject interface. There are several ways of looking at this problem: it's existed since the start of the OTS and hasn't been seen as a problem so we leave it (although we could put some text into the specification to warn programmers about the possibility), or we agree that it's such a significant problem that it must be addressed. I'd prefer the latter, but *only* if it's still possible to prevent context propagation. > It can't be a POA attribute because the decision as to whether to send > a context must be made on the client side. Is that true? I hope it's not or I can see the problem more from your side! It was my understanding that the transactionality of an object could still be determined by the client "somehow". Some historical background to put my discussion into context: when TransactionalObject was being considered to be dropped I was asked by someone on the AB what the implications of this would be - it was about 18+ months ago if I remember correctly, and the POA was still being developed. I was told by this AB member that TransactionalObject was being replaced by a POA attribute but that the client would still be able to determine transactionality by the IOR of the object (he said that attributes were encoded within it). I haven't checked this statement since, and just assumed it was correct! If this is not the case then I understand your concerns!! > > > The default would be to > > not send the context unless the target is explicitly > transactional, but > > allowing more control to the user. > > There is *no* way to find out whether the target is > transactional. It > may be transactional on every second Tuesday only, and > non-transactional > the rest of the time. In turn, this means that you cannot even make > this > part of the profile information (or some other part) of the object's > IOR. > > However, there is no problem. If, as an application programmer, I > want > to be sure that a particular call is sent non-transactionally (is > that a > word? ;-), I can simply call suspend(), make the call, and call > resume(). > > So, I think we must force propagation of the context regardless of > the > destination of a call, and we must force non-transactional object to > pass that context on if they make further calls. That's simply the > cost > of using transactions. If I don't want the cost, I shouldn't be > using > transactions (or call suspend). I can't have the cake and it it > too... If the attribute of the object can't be determined then I agree (roughly) with this. However, I'd like some clarification of the effect of POA attributes on IORs, if any. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Architect (Transactions), Arjuna Solutions PHONE : +44 191 222 8066, FAX : +44 191 222 8232 EMAIL : mark@arjuna.com Date: Wed, 9 Feb 2000 20:45:54 +1000 (EST) From: Michi Henning To: Mark Little cc: ots-rtf@omg.org Subject: Re: I In-Reply-To: <095401bf72e8$cfebcee0$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: QjK!!WB`!!+AGe9TF$e9 On Wed, 9 Feb 2000, Mark Little wrote: > >From a purist POV we don't have an argument here. However, as I said I can > see why not propagating is required, and I thought that because that > requirement was important was one reason why the POA attribute was being > added to *replace* TransactionalObject. Hmmm... I don't see how a POA attribute would help to decide whether or not to propagate a transaction context. After all, it's the client that must decide whether or not to add the service context, and the client can't see the POA attribute (policy?) of the target object. Sorry, I'm confused here... > > I don't see this myself. A transaction context will get huge only if > > we have very deeply nested transactions. I cannot see a nesting level > > of more than 4 or 5 transactions even in the most complex application. > > You're placing restrictions on the types of applications that can be > performant then? So you'd also like to see some constraint on the number of > nested transactions? I don't think so. I can have as deeply nested an > invocation as I want in CORBA, and lets say that at each object my > invocation passes through I get a new nested transaction started. It's > really easy to get deeply nested transactions. Just because you can't see it > doesn't mean it won't/can't happen. Sure, no argument there. But I can't expect that to happen at zero cost. Just because I can't see it, that doesn't mean that I can afford to be ignorant of what goes on behind the scenes. That's just like ignoring that a network is present altogether. CORBA hides the network pretty much completely, but that doesn't mean that I can forget that it is there. Transactions are much the same thing. If I nest my transactions fifty deep, I'll have slower invocations. That's fair enough to me. > In the past I have tried it with pre-CORBA RPCs and once you start > fragmenting the message buffer (e.g., 1400+ bytes on ethernet) the > cost goes > up. Since the transaction context contains object references > (Coordinators, > and possible Terminators, + implementation specific data), the > context size > even with "only" 4 levels of nesting could quickly go over this. Sure, but so what? I can't expect transactions to be free. After all, they do an awful lot of work for me, so why should I expect that they have no run-time cost? > > > My current preference to a "solution" is that we tighten up the text > > > (allowing contexts to not be propagated) and essentially warn > programmers > > > about the "tx object-to non-tx object-to tx-object" problem. > > > > I am utterly and dead-set against this. It would mean that I cannot have > > any guarantee whatsoever about sane behavior. How would I tell under > > what circumstances a context will or won't be propagated? > > You have the POA attribute in the receiver! But it's the sender that must decide whether or not to send the context, so the POA attribute (I think you mean policy?) won't help. What am I missing? > > And, if I have > > the bad luck of calling into a transactional object (which I do > not > control) > > which in turn calls a non-transactional object (without my > knowledge) > > which in turn calls one of the objects I currently have in the > transaction, > > I get inexplicable (and unfixable) deadlocks. This isn't sane > behavior. > > That's another matter, and comes back to my original "historical" > point > about the TransactionalObject interface. There are several ways of > looking > at this problem: it's existed since the start of the OTS and hasn't > been > seen as a problem so we leave it (although we could put some text > into the > specification to warn programmers about the possibility), or we > agree that > it's such a significant problem that it must be addressed. I'd > prefer the > latter, but *only* if it's still possible to prevent context > propagation. I prefer the latter too. And, to be honest, there are quite a lot of things that have existed since the start of the OTS and haven't been seen as a problem, but turned out to cause significant problems nevertheless :-) > > It can't be a POA attribute because the decision as to whether to send > > a context must be made on the client side. > > Is that true? I hope it's not or I can see the problem more from your side! > It was my understanding that the transactionality of an object could still > be determined by the client "somehow". Well, that "somehow" must come from somewhere. If it's not in the object, it can only be in the reference. I can't see any other place to put it. > Some historical background to put my > discussion into context: when TransactionalObject was being > considered to be > dropped I was asked by someone on the AB what the implications of > this would > be - it was about 18+ months ago if I remember correctly, and the > POA was > still being developed. I was told by this AB member that > TransactionalObject > was being replaced by a POA attribute but that the client would > still be > able to determine transactionality by the IOR of the object (he said > that > attributes were encoded within it). I haven't checked this statement > since, > and just assumed it was correct! If this is not the case then I > understand > your concerns!! Well, I have never even heard of such a thing. Do you have a reference somewhere? I thought I knew the POA quite well actually ;-) but I've never come across such an animal... > > However, there is no problem. If, as an application programmer, I want > > to be sure that a particular call is sent non-transactionally (is that a > > word? ;-), I can simply call suspend(), make the call, and call resume(). > > > > So, I think we must force propagation of the context regardless of the > > destination of a call, and we must force non-transactional object to > > pass that context on if they make further calls. That's simply the cost > > of using transactions. If I don't want the cost, I shouldn't be using > > transactions (or call suspend). I can't have the cake and it it too... > > If the attribute of the object can't be determined then I agree (roughly) > with this. However, I'd like some clarification of the effect of POA > attributes on IORs, if any. Well, I haven't heard of this policy (POAs have policies, not attributes, just to be picky ;-) If there were such a policy, it could be made visible by adding a component to each IOR. However, no such component has been defined in the spec. Even if there were such a component, it still wouldn't help with the chained call scenario I outlined, where we call via intermediate non-transactional objects. So, I honestly believe that we have no choice. Always propagating the context seems the only sensible thing to do. If I can't afford that, I can suspend the transaction before making a call. 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 From: "Mark Little" To: "Michi Henning" Cc: References: Subject: Re: I Date: Wed, 9 Feb 2000 10:54:42 -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: ~Ygd9#~2e9T;Ud9-LVd9 ----- Original Message ----- From: Michi Henning To: Mark Little Cc: Sent: Wednesday, February 09, 2000 10:45 AM Subject: Re: I > > Some historical background to put my > > discussion into context: when TransactionalObject was being > considered to be > > dropped I was asked by someone on the AB what the implications of > this would > > be - it was about 18+ months ago if I remember correctly, and the > POA was > > still being developed. I was told by this AB member that TransactionalObject > > was being replaced by a POA attribute but that the client would > still be > > able to determine transactionality by the IOR of the object (he > said that > > attributes were encoded within it). I haven't checked this > statement since, > > and just assumed it was correct! If this is not the case then I understand > > your concerns!! > > Well, I have never even heard of such a thing. Do you have a > reference > somewhere? I thought I knew the POA quite well actually ;-) but I've > never > come across such an animal... I won't bother at the moment with the rest of your email since it looks like the above is the key point in our discussion. Unfortunately I don't have a printed account of this, and I'm searching my email store for something. But my recollection on this is pretty good since my point to the AB member was essentially that (ignoring the distribution transparency problem that's existed from the start for the moment) without TransactionalObject you'd never know whether or not to propagate the context from client to server. So his answer of "the POA attribute is encoded in the IOR" was sufficient. If this isn't the case (and if you say it isn't I tend to believe you on this) then we have no choice but to always propagate! 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: Wed, 9 Feb 2000 21:03:46 +1000 (EST) From: Michi Henning To: Mark Little cc: ots-rtf@omg.org Subject: Re: I In-Reply-To: <09ea01bf72ec$1256f400$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: iJ)e9O,,!!g@2!!&b%!! On Wed, 9 Feb 2000, Mark Little wrote: > I won't bother at the moment with the rest of your email since it looks like > the above is the key point in our discussion. Unfortunately I don't have a > printed account of this, and I'm searching my email store for something. But > my recollection on this is pretty good since my point to the AB member was > essentially that (ignoring the distribution transparency problem that's > existed from the start for the moment) without TransactionalObject you'd > never know whether or not to propagate the context from client to server. So > his answer of "the POA attribute is encoded in the IOR" was sufficient. If > this isn't the case (and if you say it isn't I tend to believe you on this) > then we have no choice but to always propagate! Well, I have never heard of such a thing. Being very active in both the Core and Interop RTFs, I'd be surprised if had missed it. Also, examination of both the POA spec and the GIOP/IIOP spec yields no hint to such a thing. 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 From: "Mark Little" To: "Michi Henning" Cc: References: Subject: Re: I Date: Wed, 9 Feb 2000 11:20:40 -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: QHi!!5^h!!~H(e9aAH!! I managed to find something in my mail archive on the subject of removing TransactionalObject and "replacing" it with attributes. This is what I had to say in April 1998: >deprecating TransactionalObject: as far as I can see, the move to using >attributes instead of the TransactionalObject interface seems fine. >Transactionality is definitely a property of the implementation rather >than the interface. As long as it's still possible for the client to >determine the object's transactionality before the call is made (which >appears to be the case), then this change is for the better. It seems as >though the transactional attribute is set on a per object basis, so the >server can still handle transactional and non-transactional objects >concurrently, which is the right way to do it, (and is obviously >supported in the current OTS spec. through TransactionalObject.) As far as I can see, if what you say is true, and no transactionality attribute of the server object can be determined by the client, then the implications of the change from TransactionalObject to POA attribute were not fully considered. It did not (as I suspect was assumed) simply replace TransactionalObject with a more flexible mechanism: it removed an important feature, i.e., the ability to determine transactionality. This then means that this is an extremely important issue to resolve. I think Ed was involved in the change at some point, so may be able to shed some light on this. However, if there is no possibility of changes to enable the client to determine server transactionality, then we have no option but to change the specification so that the transaction context is always propagated. 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: Wed, 09 Feb 2000 08:10:14 -0500 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Little CC: Michi Henning , ots-rtf@omg.org Subject: Re: I References: <0a7401bf72ef$b286eb80$6e96f080@ncl.ac.uk> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: $k'e9e3Je9n3pd9_!!"! Is it possible that this is just confused terminology, and you are talking about the server side TransactionPolicy and TransactionPolicyComponent that the Messaging spec defined? The TransactionPolicy specifies the transactionality of the objects implemented in the POA to which its passed, and results in a TransactionPolicyComponent being included in those objects' IORs that indicates their transactionality to the client. The TransactionalObject interface was deprecated. See section 9.5 of orbos/98-05-05 (or possibly a newer draft from the Messaging RTF). -Bob Mark Little wrote: > > I managed to find something in my mail archive on the subject of > removing > TransactionalObject and "replacing" it with attributes. This is what > I had > to say in April 1998: > > >deprecating TransactionalObject: as far as I can see, the move to > using > >attributes instead of the TransactionalObject interface seems fine. > >Transactionality is definitely a property of the implementation > rather > >than the interface. As long as it's still possible for the client > to > >determine the object's transactionality before the call is made > (which > >appears to be the case), then this change is for the better. It > seems as > >though the transactional attribute is set on a per object basis, so > the > >server can still handle transactional and non-transactional objects > >concurrently, which is the right way to do it, (and is obviously > >supported in the current OTS spec. through TransactionalObject.) > > As far as I can see, if what you say is true, and no > transactionality > attribute of the server object can be determined by the client, then > the > implications of the change from TransactionalObject to POA attribute > were > not fully considered. It did not (as I suspect was assumed) simply > replace > TransactionalObject with a more flexible mechanism: it removed an > important > feature, i.e., the ability to determine transactionality. This then > means > that this is an extremely important issue to resolve. I think Ed was > involved in the change at some point, so may be able to shed some > light on > this. However, if there is no possibility of changes to enable the > client to > determine server transactionality, then we have no option but to > change the > specification so that the transaction context is always propagated. > > 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: "Bob Kukura" Cc: "Michi Henning" , References: <0a7401bf72ef$b286eb80$6e96f080@ncl.ac.uk> <38A16736.73C548D7@iona.com> Subject: Re: I Date: Wed, 9 Feb 2000 13:36:47 -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: D\Me9!ZN!!OE*!!0j]!! ----- Original Message ----- From: Bob Kukura To: Mark Little Cc: Michi Henning ; Sent: Wednesday, February 09, 2000 1:10 PM Subject: Re: I > Is it possible that this is just confused terminology, and you are > talking about the server side TransactionPolicy and > TransactionPolicyComponent that the Messaging spec defined? Not sure. At the time this was mentioned to me (pre April 1998) nothing specific in the way of classes/interfaces was described. However, the intention was clear: clients would still be able to determine a remote object's transactionality in order to know whether or not to send the context. > The > TransactionPolicy specifies the transactionality of the objects > implemented in the POA to which its passed, and results in a > TransactionPolicyComponent being included in those objects' IORs > that > indicates their transactionality to the client. The > TransactionalObject > interface was deprecated. See section 9.5 of orbos/98-05-05 (or > possibly a newer draft from the Messaging RTF). Ah, so it is possible for a client to determine the transactionality of the object it is about to invoke? Does this not conflict with Michi's interpretation? 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 Reply-To: From: "Eric Newcomer" To: "'Mark Little'" , "'Michi Henning'" , "'Blake Biesecker'" Cc: Subject: RE: I Date: Wed, 9 Feb 2000 10:25:46 -0500 Message-ID: <001601bf7311$f2038b20$b185413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <089601bf72e1$705749c0$6e96f080@ncl.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: "[""!'])!!JmW!!4-8!! Agree it's better not to send the context unless the object is transactional, which Bob pointed out is identifiable via POA policy. -----Original Message----- From: Mark Little [mailto:M.C.Little@ncl.ac.uk] Sent: Wednesday, February 09, 2000 4:39 AM To: Michi Henning; Blake Biesecker Cc: ots-rtf@omg.org Subject: Re: I ----- Original Message ----- > When it issues requests on transactional objects, the transaction > context associated with the current thread is implicitly > propagated to the object. > > That's wrong as it stands. Whether or not an object is transactional > for > a particular invocation can vary at run time. It can depend on the operation > name or even the parameter values. It follows that the client has no > way to figure whether or not a particular object is transactional. > Ergo, the only way to deal with this is to require an ORB to unconditionally > propagate the transaction context if the client has one. > > This is particularly important if I call from a client that has a > transaction to a non-transactional object, which in turn calls a > transactional object. In that case, the original transaction context > must be passed through the non-transactional object, otherwise we > break transaction propagation in inexplicable and unpredicatable > ways. >From my understanding of the POA and POI this is less of an issue than in the "old" BOA days, but the fact that it breaks location transparency can be a big problem. For example, programmer X decides to try co-locating certain objects to start with. The don't need to be derived from TransactionalObject (I know this has been dropped, but bear with me!) in order to get the transaction context, since it's implicitly associated with the thread of control. However, if he later decides that some objects must be placed in a separate process their signatures must be changed. The obvious solution to this is to force all objects, local and remote, that want the context to be derived from TransactionalObject. There are several problems with this, including the fact that the programmer may not have control over the object through which his transactional object is invoked (in Michi's example the invocation comes through a non-transactional object), his requirements may change for the object over time, and certain operations may be transactional whereas others may not. I believe that with the POA and POI, interceptors must be called even on co-located invocations, so maybe this isn't an issue any more. However, being devil's advocate, always propagating the transaction context implies a performance hit on those objects which don't need it. The size of the context, especially when you're talking about using nested transactions, may be hugh in comparison to the size of the non-transactional message invocation size. So I can see a requirement for being able to say "don't propagate". My current preference to a "solution" is that we tighten up the text (allowing contexts to not be propagated) and essentially warn programmers about the "tx object-to non-tx object-to tx-object" problem. Another option (and I'm not sure how possible this one is) would be to allow an application user/programmer to dynamically specify that contexts must be propagated all of the time - could this be another POA attribute? The default would be to not send the context unless the target is explicitly transactional, but allowing more control to the user. 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: Wed, 9 Feb 2000 11:34:56 -0800 From: Blake Biesecker To: Jeffrey Mischkinsky Cc: Michi Henning , ots-rtf@omg.org Subject: Re: I Message-ID: <20000209113456.A1170@gemstone.com> References: <200002090333.TAA06742@wheel.dcn.davis.ca.us> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <200002090333.TAA06742@wheel.dcn.davis.ca.us>; from jmischki@wheel.dcn.davis.ca.us on Tue, Feb 08, 2000 at 07:33:23PM -0800 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: J@+!![#?!!;9Td9>96e9 On Tue, Feb 08, 2000 at 07:33:23PM -0800, Jeffrey Mischkinsky wrote: > 'Michi Henning' writes: > > > > On Tue, 8 Feb 2000, Blake Biesecker wrote: > > > > Well, in the past, we have never worried about this either. For > example, > > if I want to use several naming services simultaneously, I have to > get > > all but one using some other means. However, note that with INS, > you > > can use the command line to add new tokens to what is accepted by > > resolve_initial_references. I think that solves the problem > adequately. > > > > The easy way out I can see at the moment is to state that > > resolve_initial_references("TransactionFactory") returns the > factory ref. > > > > The core spec currently also talks about "TransactionCurrent" as a > token > > for resolve_initial_references. That one causes problems when > combined > > with the above idea of having more than one OTS in a > process. That's > > because there is only one Current (it's a singleton > object). However, > > if I have two OTSs in the same process, this completely falls > apart. > > A call to resolve_initial_references("TransactionCurrent") does > not > > have enough context info to determine which of the two possible > Current > > objects I might mean... > > > > The way I see it, OTS was never designed to work with more than > one > > transaction implementation at the same time (and we probably > shouldn't try > > to make it do that). > > I think that's true and I think I agree. > I think that was an (implicit) assumption at the time. > Ask Ed, he was there "at creation" also. > > jeff > I can live with one TransactionFactory reference per orb instance. Are people comfortable with changing (10-21): A TransactionFactory is located using the FactoryFinder interface of the life cycle service and not by the resolve_initial_reference operation on the ORB interface defined in "Example Object Adapters" in Chapter 2 of the Common Object Request Broker: Architecture and Specification. to: A TransactionFactory is located using the resolve_initial_reference operation with a reserved ObjectId of "TransactionFactory" on the ORB interface as defined in "Obtaining Initial Object References" in section 4.7 of the Common Object Request Broker: Architecture and Specification. To be thorough, we should probably arrante to change section 4.7 of the CORE to list "TransactionFactory" as one of the reserved ObjectIds as well. Blake Date: Thu, 10 Feb 2000 07:44:27 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: Jeffrey Mischkinsky , ots-rtf@omg.org Subject: Re: I In-Reply-To: <20000209113456.A1170@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 22Qe9Y=-e9+7X!!/0G!! On Wed, 9 Feb 2000, Blake Biesecker wrote: > Are people comfortable with changing (10-21): Yes, I'm comfortable with that. 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 X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Feb 2000 14:51:38 -0800 To: Michi Henning , Blake Biesecker From: Edward Cobb Subject: Re: I Cc: ots-rtf@omg.org In-Reply-To: References: <20000208174156.G430@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: O/$"!IB>e9Je~!!Zh*!! Michi is right on this one. I thought it was all fixed by the messaging changes, but if not, it's fair for the RTF to do so since the base document has incorporated the changes from messaging. At 12:23 PM 2/9/00 +1000, Michi Henning wrote: >On Tue, 8 Feb 2000, Blake Biesecker wrote: > >> This issue is similar to 2933. It is resolved by the Messaging >> spec. (Michi please let me know if you feel that this issue >> is not adequately addressed there.) > >It looks like it is (well almost). On page 10-37 (in the merged document): > > When it issues requests on transactional objects, the transaction > context associated with the current thread is implicitly > propagated to the object. > >That's wrong as it stands. Whether or not an object is transactional for >a particular invocation can vary at run time. It can depend on the operation >name or even the parameter values. It follows that the client has no >way to figure whether or not a particular object is transactional. >Ergo, the only way to deal with this is to require an ORB to unconditionally >propagate the transaction context if the client has one. > >This is particularly important if I call from a client that has a >transaction to a non-transactional object, which in turn calls a >transactional object. In that case, the original transaction context >must be passed through the non-transactional object, otherwise we >break transaction propagation in inexplicable and unpredicatable ways. > >So, I think that we must oblige an ORB to not throw any part of the >service context away for chained calls. > > 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 ************************************************************** X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Feb 2000 14:54:11 -0800 To: Michi Henning , Blake Biesecker From: Edward Cobb Subject: Re: I Cc: ots-rtf@omg.org In-Reply-To: References: <20000208175456.H430@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: lRLd9PFld9Vh7!!7l&!! Michi is correct again. After minimal discussion, we (the original OTS submitters) abandoned the idea of trying to support more than a single OTS implementation in a "process" (whatever that is). At 12:45 PM 2/9/00 +1000, Michi Henning wrote: >On Tue, 8 Feb 2000, Blake Biesecker wrote: > >> At the very least, I think we should remove this section from >> the spec. If we others think it is important to mention how >> to find a TransactionFactory, > >I agree. What's in there now is pure fantasy material. > >> I don't have a problem I have with >> using resolve_initial_references, although we might want to >> discuss the need to find more than one TransactionFactory. >> (So, just allowing resolve_initial_references("TransactionFactory") >> might not meet needs of all applications.) >> >> comments? suggestions? > >Well, in the past, we have never worried about this either. For >> example, >if I want to use several naming services simultaneously, I have to >> get >all but one using some other means. However, note that with INS, you >can use the command line to add new tokens to what is accepted by >resolve_initial_references. I think that solves the problem >> adequately. > >The easy way out I can see at the moment is to state that >resolve_initial_references("TransactionFactory") returns the factory >> ref. > >The core spec currently also talks about "TransactionCurrent" as a >> token >for resolve_initial_references. That one causes problems when >> combined >with the above idea of having more than one OTS in a process. That's >because there is only one Current (it's a singleton object). However, >if I have two OTSs in the same process, this completely falls apart. >A call to resolve_initial_references("TransactionCurrent") does not >have enough context info to determine which of the two possible >> Current >objects I might mean... > >The way I see it, OTS was never designed to work with more than one >transaction implementation at the same time (and we probably >> shouldn't try >to make it do that). > > 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 ************************************************************** X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Feb 2000 14:59:09 -0800 To: Jeffrey Mischkinsky , michi@ooc.com.au (Michi Henning) From: Edward Cobb Subject: Re: I Cc: blakeb@gemstone.com (Blake Biesecker), ots-rtf@omg.org In-Reply-To: <200002090333.TAA06742@wheel.dcn.davis.ca.us> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: FkR!!03+!!"FP!!fN`!! I think I confirmed this in an earlier note. OTS was not intended, by its creators (that sounds really ominous), to support multiple implementations at the same time. At 07:33 PM 2/8/00 -0800, Jeffrey Mischkinsky wrote: >'Michi Henning' writes: >> >> On Tue, 8 Feb 2000, Blake Biesecker wrote: >> >> Well, in the past, we have never worried about this either. For example, >> if I want to use several naming services simultaneously, I have to get >> all but one using some other means. However, note that with INS, you >> can use the command line to add new tokens to what is accepted by >> resolve_initial_references. I think that solves the problem adequately. >> >> The easy way out I can see at the moment is to state that >> resolve_initial_references("TransactionFactory") returns the factory ref. >> >> The core spec currently also talks about "TransactionCurrent" as a token >> for resolve_initial_references. That one causes problems when combined >> with the above idea of having more than one OTS in a process. That's >> because there is only one Current (it's a singleton object). However, >> if I have two OTSs in the same process, this completely falls apart. >> A call to resolve_initial_references("TransactionCurrent") does not >> have enough context info to determine which of the two possible Current >> objects I might mean... >> >> The way I see it, OTS was never designed to work with more than one >> transaction implementation at the same time (and we probably shouldn't try >> to make it do that). > >I think that's true and I think I agree. >I think that was an (implicit) assumption at the time. >Ask Ed, he was there "at creation" also. > > jeff > > > >-- >Jeff Mischkinsky >jmischki@dcn.davis.ca.us +1 530-758-9850 >jeff@persistence.com +1 650-372-3604 > > ************************************************************** 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 ************************************************************** Reply-To: From: "Eric Newcomer" To: "'Edward Cobb'" , "'Michi Henning'" , "'Blake Biesecker'" Cc: Subject: RE: I Date: Wed, 9 Feb 2000 18:07:08 -0500 Message-ID: <006001bf7352$6446b050$b185413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3.0.5.32.20000209145138.00b57b00@svlhome2.beasys.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Z/Ke96TUd9)R(!!@U%!! Now I'm confused. Is there or isn't there a way for the client to find out the server is transactional? -----Original Message----- From: Edward Cobb [mailto:ed.cobb@beasys.com] Sent: Wednesday, February 09, 2000 5:52 PM To: Michi Henning; Blake Biesecker Cc: ots-rtf@omg.org Subject: Re: I Michi is right on this one. I thought it was all fixed by the messaging changes, but if not, it's fair for the RTF to do so since the base document has incorporated the changes from messaging. At 12:23 PM 2/9/00 +1000, Michi Henning wrote: >On Tue, 8 Feb 2000, Blake Biesecker wrote: > >> This issue is similar to 2933. It is resolved by the Messaging >> spec. (Michi please let me know if you feel that this issue >> is not adequately addressed there.) > >It looks like it is (well almost). On page 10-37 (in the merged document): > > When it issues requests on transactional objects, the transaction > context associated with the current thread is implicitly > propagated to the object. > >That's wrong as it stands. Whether or not an object is transactional for >a particular invocation can vary at run time. It can depend on the operation >name or even the parameter values. It follows that the client has no >way to figure whether or not a particular object is transactional. >Ergo, the only way to deal with this is to require an ORB to unconditionally >propagate the transaction context if the client has one. > >This is particularly important if I call from a client that has a >transaction to a non-transactional object, which in turn calls a >transactional object. In that case, the original transaction context >must be passed through the non-transactional object, otherwise we >break transaction propagation in inexplicable and unpredicatable ways. > >So, I think that we must oblige an ORB to not throw any part of the >service context away for chained calls. > > 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: Tue, 8 Feb 2000 17:54:57 -0800 From: Blake Biesecker To: ots-rtf@omg.org Subject: I Message-ID: <20000208175456.H430@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: [+Ee9E`!"![36e9d6J!! At the very least, I think we should remove this section from the spec. If we others think it is important to mention how to find a TransactionFactory, I don't have a problem I have with using resolve_initial_references, although we might want to discuss the need to find more than one TransactionFactory. (So, just allowing resolve_initial_references("TransactionFactory") might not meet needs of all applications.) comments? suggestions? Blake issue archive: ------------------------------- Issue 2934: ots-rtf: TransactionFactory (ots-rtf) Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: Page 10-21: A TransactionFactory is located using the FactoryFinder interface of the life cycle service and not by the resolve_initial_reference operation on the ORB interface defined in "Example Object Adapters" in Chapter 2 of the Common Object Request Broker: Architecture and Specification. There are a number of issues here: 1) The section referred to here no longer exists. 2) The life cycle is not an optional component of CORBA. Yet, it appears that OTS cannot be implemented without the Life Cycle Service. 3) Neither OTS nor the Life Cycle Service make a statement as to how I could obtain the FactoryFinder interface that I need to get the transaction factory. I therefore cannot write portable code. 4) The OTS spec makes no statement as to, once I have obtained a factory finder, what factory name I should provide to the find_factories() operation in order to obtain a reference to the transaction factory, so it is impossible to write portable code. 5) We already have resolve_initial_references to solve initial reference problem. Why use a factory finder for this then? In particular, resolve_initial_references("TransactionCurrent") is already in use to obtain a reference to the Current object, so why have two different mechanism for locating initial objects within the same service? Resolution: Revised Text: Actions taken: October 11, 1999: received issue Discussion: End of Annotations:===== Date: Mon, 11 Oct 1999 14:24:10 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: issues@omg.org Subject: ots-rtf: TransactionFactory Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Page 10-21: A TransactionFactory is located using the FactoryFinder interface of the life cycle service and not by the resolve_initial_reference operation on the ORB interface defined in "Example Object Adapters" in Chapter 2 of the Common Object Request Broker: Architecture and Specification. There are a number of issues here: 1) The section referred to here no longer exists. 2) The life cycle is not an optional component of CORBA. Yet, it appears that OTS cannot be implemented without the Life Cycle Service. 3) Neither OTS nor the Life Cycle Service make a statement as to how I could obtain the FactoryFinder interface that I need to get the transaction factory. I therefore cannot write portable code. 4) The OTS spec makes no statement as to, once I have obtained a factory finder, what factory name I should provide to the find_factories() operation in order to obtain a reference to the transaction factory, so it is impossible to write portable code. 5) We already have resolve_initial_references to solve initial reference problem. Why use a factory finder for this then? In particular, resolve_initial_references("TransactionCurrent") is already in use to obtain a reference to the Current object, so why have two different mechanism for locating initial objects within the same service? 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: <200002100011.QAA11922@wheel.dcn.davis.ca.us> Subject: Re: I To: eric.newcomer@iona.com Date: Wed, 9 Feb 2000 16:11:29 -0800 (PST) Cc: ed.cobb@beasys.com ('Edward Cobb'), michi@ooc.com.au ('Michi Henning'), blakeb@gemstone.com ('Blake Biesecker'), ots-rtf@omg.org In-Reply-To: <006001bf7352$6446b050$b185413f@boston.amer.iona.com> from "Eric Newcomer" at Feb 09, 2000 06:07:08 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: lWhd9:(md9e~Ke91f;e9 'Eric Newcomer' writes: > > Now I'm confused. Is there or isn't there a way for the client to > find out > the server is transactional? It has to check to see if the proper tag component is present in the IOR. jeff > > -----Original Message----- > From: Edward Cobb [mailto:ed.cobb@beasys.com] > Sent: Wednesday, February 09, 2000 5:52 PM > To: Michi Henning; Blake Biesecker > Cc: ots-rtf@omg.org > Subject: Re: I > > Michi is right on this one. I thought it was all fixed by the > messaging > changes, but if not, it's fair for the RTF to do so since the base > document > has incorporated the changes from messaging. > > At 12:23 PM 2/9/00 +1000, Michi Henning wrote: > >On Tue, 8 Feb 2000, Blake Biesecker wrote: > > > >> This issue is similar to 2933. It is resolved by the Messaging > >> spec. (Michi please let me know if you feel that this issue > >> is not adequately addressed there.) > > > >It looks like it is (well almost). On page 10-37 (in the merged > document): > > > > When it issues requests on transactional objects, the > transaction > > context associated with the current thread is implicitly > > propagated to the object. > > > >That's wrong as it stands. Whether or not an object is > transactional for > >a particular invocation can vary at run time. It can depend on the > operation > >name or even the parameter values. It follows that the client has > no > >way to figure whether or not a particular object is transactional. > >Ergo, the only way to deal with this is to require an ORB to > unconditionally > >propagate the transaction context if the client has one. > > > >This is particularly important if I call from a client that has a > >transaction to a non-transactional object, which in turn calls a > >transactional object. In that case, the original transaction > context > >must be passed through the non-transactional object, otherwise we > >break transaction propagation in inexplicable and unpredicatable > ways. > > > >So, I think that we must oblige an ORB to not throw any part of the > >service context away for chained calls. > > > > 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 > ************************************************************** > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Thu, 10 Feb 2000 12:22:17 +1000 (EST) From: Michi Henning To: Eric Newcomer cc: "'Edward Cobb'" , "'Blake Biesecker'" , ots-rtf@omg.org, messaging-rtf@omg.org Subject: RE: I In-Reply-To: <006001bf7352$6446b050$b185413f@boston.amer.iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 3R!e9H>ld9'%"!!^-7!! On Wed, 9 Feb 2000, Eric Newcomer wrote: > Now I'm confused. Is there or isn't there a way for the client to find out > the server is transactional? OK, first of all, apologies are due. I totally confused the issue by somehow missing the bit added by the messaging spec. Having refreshed my memory, here is a big tirade about these changes. Please bear with me, even though this has turned into a rather long message. Some comments on these changes: - The text at the bottom of page 10-35 talks about TransactionalObject, but at the top of 10-35, TransactionalObject has been deleted. The two edits don't go together, so we need to fix this. - The specification of the component to use for the transaction policy is incomplete. Chapters 13 and 15 will require updates for this as well. (The component must be specified there too.) - The module CosTSInteroperation is not specified in section 10.6 of the document. (In general, I think a sanity check to make sure that 10.6 agrees with the remainder of the document would be very useful.) - interface TransactionPolicy has an attribute of type TransactionPolicyValue. That type is never defined. - CosTSInteroperation defines what goes into the component as: struct TransactionPolicyComponent { TransactionPolicyValue tpv; }; Why does this define a struct with a single member? This would appear to be useless -- the component might as well contain the TransactionPolicyValue directly. Now, let's assume for the moment that we have this component in IORs. The client side now needs to decide whether or not to send a transaction context, based on what's in the component. Clearly, if the object requires a transaction, the sender must send a context. That leaves two cases: - The object permits a transaction. If an object permits a transaction, that leaves it to the sender's discretion as to whether a context should be sent or not. How would the sender make such a decision? I honestly can't see how an intelligent decision could be made: - There are no APIs that would permit the client application code to interrogate an IOR to see whether it allows a transaction, requires it, or refuses it. - If an object permits (but doesn't require) a transaction, the ORB can't make a reasoned decision either. It might as well toss a coin... So, neither the ORB nor the application can figure out what to do if an object permits a transaction context, but doesn't require one. - The object disallows a transaction. In that case, the semantics are also unclear. What does "disallow" mean? Does it mean that, if I have a transaction context, when I invoke an operation, I get an exception immediately? Or does it mean that if I invoke the operation, the ORB simply won't send my transaction context? To make matter worse, the table at the top of page 10-35 does not distinguish between two different cases: the second and third bullet point both have the label "1", implying that the behavior is the same whether an object allows no transaction and requires no transaction. It would appear then that, if I have an object that allows a transaction, silently no transaction content will be sent, even though I may have one? This is badly under-specified... And, what is not considered at all is what to do if an IOR does not contain the transaction component. (There is no shortage of such IORs...) In other words, what should happen if there is no TP information in an IOR at all, but I have a transaction context when I make a call? That case needs dealing with. Now, ignoring the specification deficiencies for the moment, there are still problems here. Assuming that we arrive at an answer of some kind to the above questions, what happens in the scenario I outlined earlier, where I have a call chain tx -> non-tx -> tx? As I said earlier, not propagating the transaction context across the non-transactional object leads to unpredictable and opaque failures. Please, no-one argue that this example is contrived. It is not: both the event service and the trader service use the callback pattern. (The even service to reap proxies, and the trader for dynamic properties.) In addition, the callback pattern is very widely used in CORBA. Are we seriously going to suggest that dynamic property evaluation in a trader and transactions simply can't coexist unless the trader itself uses an OTS? (I don't think that would be a defensible position architecturally...) I very strongly feel that this transaction policy idea is a bad move: 1) It puts yet another dint into the opacity of IORs if we permit the client application to interrogate the IOR for the policy value. 2) It doesn't solve a very common case, namely call chains that touch non-transactional objects. The problem is *very* serious indeed, because it occurs even without the callback pattern being used (the same problem happens for any call chain with a non-transactional object in the middle somewhere). 3) Not propagating a transaction context unconditionally means that we would create a model in which call trees, once the call chain touches a non-transactional object, must contain subtrees of only non-transactional objects below that point; otherwise, I run the risk of unpredictable and impossible to diagnose deadlock. 4) The policy approach is very complex, requiring a POA update and a GIOP/IIOP update, but doesn't solve the above scenario. If we were to go ahead with this model, I think it would have to be made more transparent. By that I mean: - If an IOR contains no transaction policy, the context is propagated. - If an IOR contains a "transaction permitted" policy, the context is propagated. - Non-transactional objects (without a policy) must propagate the incoming context down the call chain. - Transactional objects which permit or require a transactional context must pass that context down the call chain (unless they start a subtransaction themselves, of course). - If an IOR contains a "transaction prohibited" policy, the sender must implicitly suspend the transaction by not sending the context. Further, such an object is not allowed to call other objects in a transaction of its own. Now, the million Dollar question: All of the above semantics are very easily implemented without any need for complex policies whatsoever, by simply propagating transaction contexts unconditionally. There is one exception though: the ability to *prohibit* a transaction shoots a big hole through it. Why was this ability added? I find it hard to see the motivation for doing this. What does an object care if I have a transaction context when I invoke it? If it wants to do things non-transactionally, it can just suspend the transaction and go on its merry way (or, alternatively, the sending side can silently not transmit a transaction context). To me it seems that this was a case of features having gone overboard. Why does this ability exist? Can anyone shed any light on this? If we get rid of the ability to prohibit sending a transaction context, we can very simply implement the whole lot by requiring unconditional transaction propagation. That's simple, easy, requires no policy and no component, leaves IORs alone, etc. Far preferable to what we have now, IMO... 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, 09 Feb 2000 23:41:32 -0500 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Eric Newcomer , "'Edward Cobb'" , "'Blake Biesecker'" , ots-rtf@omg.org, messaging-rtf@omg.org Subject: Re: I References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: *?+e9iT""!h!*e9%g,!! Michi Henning wrote: > [potentially valid issues with the quality of this chapter of the messaging specification deleted.] > Now, let's assume for the moment that we have this component in IORs. > > The client side now needs to decide whether or not to send a transaction > context, based on what's in the component. Its actually based on two things. One is the component. The other is the transactional state of the client thread making the invocation, which is one of "None", "Shared", or "Unshared". See the table in 9.5.4.1 of orbos/98-05-05. > > Clearly, if the object requires a transaction, the sender must send > a > context. If the object requires a transaction and the client thread has an active transaction of the proper type, I believe the client must propagate the context. I haven't tracked down a definitive statement to this effect, but it should be their. > > That leaves two cases: > > - The object permits a transaction. > > If an object permits a transaction, that leaves it to the > sender's > discretion as to whether a context should be sent or not. > > How would the sender make such a decision? I honestly > can't see > how an intelligent decision could be made: Its the client ORB, not the client application that decides. See the table for details. The client ORB never fabricates a new transaction. It either propogates the existing transaction context, sends no transaction context, or raises an exception. > > - There are no APIs that would permit the client > application > code to interrogate an IOR to see whether it > allows > a transaction, requires it, or refuses it. The client application is not involved in the decision once the invocation has been made. I guess the application may need to know something about the object to do the right thing regarding transactions before making the invocation. I don't think that information is available from the ORB or OTS. Maybe the OTS should provide a way to query an object reference's TransactionPolicyValue. > > - If an object permits (but doesn't require) a > transaction, > the ORB can't make a reasoned decision either. It > might > as well toss a coin... In this case, I believe the ORB is supposed to propagate the context if a transaction is in effect, and not propagate a context if one is not in effect. > > So, neither the ORB nor the application can figure out > what > to do if an object permits a transaction context, but > doesn't > require one. I think the ORB follows the simple rule above, and the application is simply required to know what to do. > > - The object disallows a transaction. > > In that case, the semantics are also unclear. What does > "disallow" > mean? The table indicates exactly what exception is raised in each case. Basically, if transactions are disallowed, the invocation is made without a context if no transaction of the dissallowed type is active, and an exception is raised if a transaction of the dissallowed type is active. I'm not sure why the client has to be so harsh in all these cases - it would seem to me that the client ORB should make the invocation with no tranaction context being propagated in some of these cases rather than raising an exception. > > Does it mean that, if I have a transaction context, when I > invoke > an operation, I get an exception immediately? Yes. > > Or does it mean that if I invoke the operation, the ORB > simply > won't send my transaction context? This would seem more useful to me in some cases, but is not my understandig of how it is specified. There may be reasons I'm not aware of for it being specified the way it was. > > To make matter worse, the table at the top of page 10-35 does not > distinguish between two different cases: the second and third bullet > point both have the label "1", implying that the behavior is the > same > whether an object allows no transaction and requires no transaction. I'm not sure what table you are refering to, since my copy of the Messaging spec has pages numbered contiguously rather than by chapter. > > It would appear then that, if I have an object that allows a > transaction, > silently no transaction content will be sent, even though I may have > one? I haven't had a detailed read of this in a while (ever?) but my undestanding of the intent during the Messaging RFP process was that if the transaction is allowed and the client has one in effect, it will be sent. > > This is badly under-specified... It may be. > > And, what is not considered at all is what to do if an IOR does not > contain the transaction component. (There is no shortage of such > IORs...) Good question, given that TransactionalObject is being deprecated but is still in common usage. In a completely post-Messaging world where TranactionsalObject doesn't exist, I would think the lack of the component is equivalent to AllowsNeither. This (or a different default) should be explicit in the specification. But in real life, it may be necessary to try narrowing to TransactionalObject when no component is present. > > In other words, what should happen if there is no TP information in > an > IOR at all, but I have a transaction context when I make a call? > That case needs dealing with. Agreed. > > Now, ignoring the specification deficiencies for the moment, there > are still > problems here. Assuming that we arrive at an answer of some kind to > the > above questions, what happens in the scenario I outlined earlier, > where > I have a call chain tx -> non-tx -> tx? > > As I said earlier, not propagating the transaction context across > the > non-transactional object leads to unpredictable and opaque failures. > > Please, no-one argue that this example is contrived. It is not: both > the event service and the trader service use the callback > pattern. (The > even service to reap proxies, and the trader for dynamic > properties.) > In addition, the callback pattern is very widely used in CORBA. Are > we > seriously going to suggest that dynamic property evaluation in a > trader > and transactions simply can't coexist unless the trader itself uses > an OTS? (I don't think that would be a defensible position > architecturally...) I don't think these problems are introduced by the use of Policies and Components, are they? > > I very strongly feel that this transaction policy idea is a bad > move: > > 1) It puts yet another dint into the opacity of IORs if we > permit > the client application to interrogate the IOR for the > policy > value. I haven't seen an interface for interrogating the IOR for this. If one were to be provided, I wouldn't think it would be in a way that exposed the IOR or Component. I'd think it would be an operation on a local interface provided by the OTS (the Current?) that took an Object as an in parameter and returned a TransactionPolicyValue, the same type exposed to the server side application. > > 2) It doesn't solve a very common case, namely call chains > that touch non-transactional objects. The problem is > *very* > serious indeed, because it occurs even without the > callback > pattern being used (the same problem happens for any call > chain > with a non-transactional object in the middle somewhere). I won't argue at this point that there is no problem here. I'd need to think about it some more. > > 3) Not propagating a transaction context unconditionally > means > that we would create a model in which call trees, once > the > call chain touches a non-transactional object, must > contain > subtrees of only non-transactional objects below that > point; > otherwise, I run the risk of unpredictable and impossible > to > diagnose deadlock. Maybe this is why an exception is raised when a transaction is in effect and the component indicates that that transaction cannot be propagated. Lacking any other information, what would be different if a client ORB was obliged to propage a transaction if one was in effect? There would really be no additional guarentees, since that object might not implement the OTS at all, might call to another ORB that does, and that ORB might need a transaction to talk to some other object. I think maybe systems that implement OTS but don't themselves require transaction should be advertizing an AllowsShared or AllowsEither TranactionPolicyValue in the IOR component. > > 4) The policy approach is very complex, requiring a POA > update > and a GIOP/IIOP update, but doesn't solve the above > scenario. I don't think it requires either of these (except maybe to the silly dropability rules). My understanding of the Portable Interceptors specification is that it provides all the mechanism needed to implement the OTS without any special treatment by the ORB of OTS-defined Policies or Components. In fact, a different ORB service with similar semantics but different Policy and Component definitions should be just as implementable. > > If we were to go ahead with this model, I think it would have to be > made more transparent. By that I mean: > > - If an IOR contains no transaction policy, the context is > propagated. Maybe, but what would be the implications (or broken guarantees) if the server side ORB did not implement OTS? > > - If an IOR contains a "transaction permitted" policy, the > context > is propagated. I believe it is, if the call is made within a transaction. > > - Non-transactional objects (without a policy) must > propagate > the incoming context down the call chain. The can only do this if they implement OTS, and not all objects live in ORBs that do. > > - Transactional objects which permit or require a > transactional > context must pass that context down the call chain (unless > they > start a subtransaction themselves, of course). I can imagine cases where an object had absolutely no use for transactions, and this would be wasteful if not misleading. > > - If an IOR contains a "transaction prohibited" policy, the > sender > must implicitly suspend the transaction by not sending the > context. If it doesn't, I think it the client side will raise an exception. > Further, such an object is not allowed to call other objects > in a transaction of its own. This sounds a bit overly restrictive. > > Now, the million Dollar question: All of the above semantics are > very > easily implemented without any need for complex policies whatsoever, > by simply > propagating transaction contexts unconditionally. There is one > exception > though: the ability to *prohibit* a transaction shoots a big hole > through it. You also might be missing the fact that the Messaging spec introduces a second kind of transaction - the unshared transaction. This is needed for store-and-forward message routing, with transactional guarantees provided for each hop. The Policy and Component allow the parties to distinguish between these types of transactions. > > Why was this ability added? I find it hard to see the motivation for > doing > this. What does an object care if I have a transaction context when > I > invoke it? If it wants to do things non-transactionally, it can just > suspend > the transaction and go on its merry way (or, alternatively, the > sending > side can silently not transmit a transaction context). > > To me it seems that this was a case of features having gone > overboard. They may need some fine tuning. > > Why does this ability exist? Can anyone shed any light on this? In my recollection, it was motivated by two things: First, the need to distinguish between shared and unshared transactions. And second, the general discontent with the TransactionalObject approach. > > If we get rid of the ability to prohibit sending a transaction > context, > we can very simply implement the whole lot by requiring > unconditional > transaction propagation. That's simple, easy, requires no policy and > no component, leaves IORs alone, etc. > > Far preferable to what we have now, IMO... I think there are two problems with this approach: one is that the client may need some guarantee that the server is really capable of participating in the tranaction, and the second is the need to distinguish between Shared and Unshared transactions. > > 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 -Bob From: "Mark Little" To: "Blake Biesecker" , "Jeffrey Mischkinsky" Cc: "Michi Henning" , References: <200002090333.TAA06742@wheel.dcn.davis.ca.us> <20000209113456.A1170@gemstone.com> Subject: Re: I Date: Thu, 10 Feb 2000 09:13:18 -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: Ci&"!T~h!!d51e9&h6!! ----- Original Message ----- > I can live with one TransactionFactory reference per orb instance. > > Are people comfortable with changing (10-21): > > A TransactionFactory is located using the FactoryFinder interface > of the life cycle service and not by the resolve_initial_reference > operation on the ORB interface defined in "Example Object Adapters" > in Chapter 2 of the Common Object Request Broker: Architecture > and Specification. > > to: > > A TransactionFactory is located using the resolve_initial_reference > operation with a reserved ObjectId of "TransactionFactory" on the > ORB interface as defined in "Obtaining Initial Object References" > in section 4.7 of the Common Object Request Broker: Architecture > and Specification. > > To be thorough, we should probably arrante to change section 4.7 of the CORE > to list "TransactionFactory" as one of the reserved ObjectIds as well. Fine by me. 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: , "'Edward Cobb'" , "'Michi Henning'" , "'Blake Biesecker'" Cc: References: <006001bf7352$6446b050$b185413f@boston.amer.iona.com> Subject: Re: I Date: Thu, 10 Feb 2000 09:17:47 -0000