Issue 3344: OTS issue: PropagationContext and Status (ots-rtf) Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com) Nature: Uncategorized Issue Severity: Summary: I would like to raise a new OTS issue: OTS interoperation does specify no way how the transaction status can be propagated with a request and a reply. The PropagationContext is missing information about the transaction status. However, this information is essential for efficient and accurate interoperation between different OTS interoperation, and thus, the OTS should be corrected to propagate this information for interoperation. Resolution: Revised Text: Actions taken: February 22, 2000: received issue Discussion: End of Annotations:===== From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Tue, 22 Feb 2000 14:33:41 +0100 Message-Id: Subject: OTS issue: PropagationContext and Status MIME-Version: 1.0 TO: issues@omg.org, ots-rtf@omg.org CC: hanspi@adnovum.ch, urs.kuenzler@ubs.com, karsten-oliver.starr@ubs.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Tue, 22 Feb 2000 14:33:41 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Tue, 22 Feb 2000 14:33:41 +0100" X-UIDL: `# parents; Status current_status; any implementation_specific_data; }; - extend the Sender and Receiver interfaces with new operations that support the new propagation context If there is a common agreement on the proposed resolution, I'm willing to draft the votable resolution text (though UBS isn't on the list of voting members, currently). Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: "Mark Little" To: , Cc: , , References: Subject: Re: OTS issue: PropagationContext and Status Date: Thu, 24 Feb 2000 10:35:09 -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: 2oO!!4XX!!MRU!!]&pd9 ----- Original Message ----- From: To: ; Cc: ; ; Sent: Tuesday, February 22, 2000 1:33 PM Subject: OTS issue: PropagationContext and Status > Hello > > I would like to raise a new OTS issue: > OTS interoperation does specify no way how the transaction status can be > propagated with a request and a reply. The PropagationContext is missing > information about the transaction status. However, this information is > essential for efficient and accurate interoperation between different OTS > interoperation, and thus, the OTS should be corrected to propagate this > information for interoperation. Why does this information need to be propagated? Surely it's implied: i) if the transactional client is communicating with a transactional object it will only send the context if the transaction is StatusActive. I can see no other (valid) reason why you would want to ship a context to a transactional object for a transaction that is in another state (e.g., StatusCommitting/StatusPreparing). ii) if the transaction has moved "beyond" active, i.e., is either preparing, committing or rolling back, then the only valid communication the coordinator will have will be with resources, which should be transactional objects anyway. The status of the transaction is therefore implied by the method that is invoked on the resource (I'd hope that a committing transaction wouldn't invoke rollback on a resource, for example). Maybe I'm missing something here, but it doesn't seem necessary to piggyback this information within the context information. All the best, Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk From: "Mark Little" To: "Mark Little" , , Cc: , , References: <005701bf7eb2$d340eff0$6e96f080@ncl.ac.uk> Subject: Re: OTS issue: PropagationContext and Status Date: Thu, 24 Feb 2000 11:17:38 -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: W_\d9'^Ud9fFZd90!Td9 ----- Original Message ----- > ii) if the transaction has moved "beyond" active, i.e., is either preparing, > committing or rolling back, then the only valid communication the > coordinator will have will be with resources, which should be transactional ^^^^^^^ please insert 'not' 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: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 24 Feb 2000 13:27:40 +0100 Message-Id: Subject: Re: OTS issue: PropagationContext and Status MIME-Version: 1.0 TO: M.C.Little@ncl.ac.uk, ots-rtf@omg.org CC: hanspi@adnovum.ch, urs.kuenzler@ubs.com, karsten-oliver.starr@ubs.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 24 Feb 2000 13:27:40 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Thu, 24 Feb 2000 13:27:40 +0100" X-UIDL: YmT!!G"kd9:GN!!Bicd9 My point is mainly that the transaction status has to be propagated back as part of the reply. I agree that an ORB should not send any requests to transactional objects if the transaction status is not active, although I think it is not illegal according to the OTS spec. But exactly for that reason the transaction status has to be returned back as part of the reply otherwise the local transaction component has no efficient means to know whether e.g. the transaction has been marked for rollback. If it is all the subsequent work by the client application will just produce useless overhead. Note that by the OTS changes introduced by the Messaging Spec (see ptc/99-10-07), it's not implementation-specific anymore whether the ProgpagationContext has to be returned back. Regards Hans M.C.Little@ncl.ac.uk] wrote: > > Hello > > > > I would like to raise a new OTS issue: > > OTS interoperation does specify no way how the transaction > status can be > > propagated with a request and a reply. The > PropagationContext is missing > > information about the transaction status. However, this > information is > > essential for efficient and accurate interoperation between > different OTS > > interoperation, and thus, the OTS should be corrected to > propagate this > > information for interoperation. > > Why does this information need to be propagated? Surely it's > implied: > > i) if the transactional client is communicating with a > transactional object > it will only send the context if the transaction is > StatusActive. I can see > no other (valid) reason why you would want to ship a context to a > transactional object for a transaction that is in another state > (e.g., > StatusCommitting/StatusPreparing). To be precise, it will only send the request if the transaction is StatusActive. > > ii) if the transaction has moved "beyond" active, i.e., is > either preparing, > committing or rolling back, then the only valid communication the > coordinator will have will be with resources, which should be > transactional > objects anyway. The status of the transaction is therefore > implied by the > method that is invoked on the resource (I'd hope that a committing > transaction wouldn't invoke rollback on a resource, for example). > > Maybe I'm missing something here, but it doesn't seem > necessary to piggyback > this information within the context information. > > All the best, > > Mark. > > -------------------------------------------------------------- > --------- > SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems > Research. > PHONE : +44 191 222 8066, FAX : +44 191 222 8232 > POST : Department of Computing Science, University of Newcastle > upon > Tyne, UK, NE1 7RU > EMAIL : M.C.Little@newcastle.ac.uk > > > From: "Mark Little" To: , Cc: , , References: Subject: Re: OTS issue: PropagationContext and Status Date: Thu, 24 Feb 2000 12:40:52 -0000 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: L*Fe9K6Xd9W#dd9^)G!! ----- Original Message ----- > My point is mainly that the transaction status has to be propagated back as > part of the reply. > > I agree that an ORB should not send any requests to transactional objects if > the transaction status is not active, although I think it is not illegal > according to the OTS spec. It's not illegal, only pointless. > > But exactly for that reason the transaction status has to be > returned back as > part of the reply otherwise the local transaction component has no efficient > means to know whether e.g. the transaction has been marked for > rollback. If it > is all the subsequent work by the client application will just > produce useless > overhead. You're talking about possible optimisations which would be up to the OTS implementer to provide if they required them. If you wanted to implement this you could do it in a number of ways, e.g.,: (i) send the status back in the implementation_specific_data field (ii) when rollback_only is called on an interposed coordinator have it call the root coordinator immediately as well. Even were this change to be made then this will still be the case if explicit propagation is used. Are you suggesting we modify Control to have a status field within it to fix that problem? > > Note that by the OTS changes introduced by the Messaging Spec (see > ptc/99-10-07), it's not implementation-specific anymore whether the > ProgpagationContext has to be returned back. Agreed. 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: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 24 Feb 2000 14:19:33 +0100 Message-Id: Subject: RE: Re: OTS issue: PropagationContext and Status MIME-Version: 1.0 TO: hans.kneubuehl@ubs.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org CC: hanspi@adnovum.ch, urs.kuenzler@ubs.com, karsten-oliver.starr@ubs.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 24 Feb 2000 14:19:33 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Thu, 24 Feb 2000 14:19:33 +0100" X-UIDL: ?9_d9#[Sd91$(e9]-e!! > > You're talking about possible optimisations which would be up > to the OTS > implementer to provide if they required them. If you wanted > to implement > this you could do it in a number of ways, e.g.,: > IMO it is more than just a possible optimisation. It is basic for OTS implementations. It's just the straight way to do it. Of course, there are other ways to get the transaction status back to the client OTS component. But they all look just like workarounds because someone has forgotten to include it in the PropagationContext in the first place. I agree that we can't call this a "functionality defect", but to me it is clearly a "design defect". Or, let's look at it the other way round. Are there any drawbacks from including it in the PropagationContext. Even, we could allow implementations to just return StatusActive with the same effect as not returning the status. Probably we can't even assure that a "bad" implementation will set the status accurately. But at least, it gives the "good" OTS implementations the chance to do it. > (i) send the status back in the implementation_specific_data field That's not a valid solution for standard OTS interoperation where I am aiming at. We have perfectly solved this issue for our OTS implementation, but it won't work if different OTS domains are involved in the same transaction. > (ii) when rollback_only is called on an interposed > coordinator have it call > the root coordinator immediately as well. > I can also have Current::get_status inquiring all the participating coordinators. It's just contrary to common sense if you can easily have this in a much cheaper and more elegant way. > Even were this change to be made then this will still be the case if > explicit propagation is used. Are you suggesting we modify > Control to have a > status field within it to fix that problem? > No, the implicit transaction context is transferred by the PropagationContext, no matter whether implicit or explicit propagation is used. There are two ways to propagate the transaction, what OTS calls implicit and explcit propagation. But there is only one transaction context transfer mechanism. In Transaction Propagation in 10.5.2 it is stated: "When the Control object is passed as an operation argument (explicit propagation), no special transfer mechansim is needed." Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: "Mark Little" To: , Cc: , , References: Subject: Re: Re: OTS issue: PropagationContext and Status Date: Thu, 24 Feb 2000 13:36:15 -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: n*gd99I!!!U-:!!)eIe9 ----- Original Message ----- > IMO it is more than just a possible optimisation. It is basic for OTS > implementations. No, I disagree. Calling rollback_only simply states that the only outcome for the transaction is for it to rollback. The specification does not mandate any specific implementation for this, or that the status from a subordinate coordinator need be propagated back to the root coordinator. It does this for a reason: to let you, the implementer, find the "right" way of doing it for you. It's wrong to suppose there is a single right way to do this: the "logical" conclusion of what you want would actually be to say that if the status is propagated back to the root coordinator then it should immediately send out an "update your status" call (or whatever) to every single other subordinator coordinator it knows about, simply to stop them doing "wasted" work. Remember, implementations may be multi-threaded, so a root coordinator may have many concurrent active subordinator coordinators. > It's just the straight way to do it. Of course, there are > other ways to get the transaction status back to the client OTS > component. But > they all look just like workarounds because someone has forgotten to include it > in the PropagationContext in the first place. I disagree that it was forgotten. If you want to accomplish the same effect then simply make sure your subordinator coordinator calls to the root coordinator when rollback_only is invoked locally. It's simple, requires no changes to the OTS, and is guaranteed to work on all implementations. > I agree that we can't call this a > "functionality defect", but to me it is clearly a "design defect". > > Or, let's look at it the other way round. Are there any drawbacks > from > including it in the PropagationContext. Even, we could allow implementations to > just return StatusActive with the same effect as not returning the > status. > Probably we can't even assure that a "bad" implementation will set > the status > accurately. But at least, it gives the "good" OTS implementations > the chance to > do it. There are a couple of "major" disadvantages: (i) changing the context structure now will have a significant effect on existing OTS implementations and applications. They would not interoperate with this. (ii) you actually need a status for every transaction in the hierarchy if you support nested transactions. Just how big do you want this context to be? > > (i) send the status back in the implementation_specific_data field > > That's not a valid solution for standard OTS interoperation where I am aiming > at. We have perfectly solved this issue for our OTS implementation, but it > won't work if different OTS domains are involved in the same transaction. Agreed, so see my previous implementation (or the one below). > > > (ii) when rollback_only is called on an interposed > > coordinator have it call > > the root coordinator immediately as well. > > > > I can also have Current::get_status inquiring all the participating > coordinators. It's just contrary to common sense if you can easily > have this in > a much cheaper and more elegant way. The "cheaper" and "more elegant" statements are not subjective. > No, the implicit transaction context is transferred by the PropagationContext, > no matter whether implicit or explicit propagation is used. Not true. The propagation context is only sent if the receiving object is transactional. The idea behind explicit propagation was to allow you to have "finer" control over which operations of an object are transactional and which are not. It's another debate entirely about whether this is actually the right thing to do, but it's in the specification and we have to live with it. So, if I use explicit propagation of the Control, I would not expect to get the PropagationContext as well implicitly. > There are two ways > to propagate the transaction, what OTS calls implicit and explcit propagation. > But there is only one transaction context transfer mechanism. > > In Transaction Propagation in 10.5.2 it is stated: "When the Control object is > passed as an operation argument (explicit propagation), no special transfer > mechansim is needed." Yes, essentially that means that no filter/interceptor mechanism will be involved, since the transaction information (the Control) is being passed as a parameter to the invocation. 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: "Mark Little" , , Cc: , , References: <016d01bf7ecc$1fb95110$6e96f080@ncl.ac.uk> Subject: Re: Re: OTS issue: PropagationContext and Status Date: Thu, 24 Feb 2000 13:56:28 -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: %Z`d9F#*e9`afd91f`d9 ----- Original Message ----- > The "cheaper" and "more elegant" statements are not subjective. > > > No, the implicit transaction context is transferred by the > PropagationContext, > > no matter whether implicit or explicit propagation is used. > > Not true. The propagation context is only sent if the receiving object is > transactional. The idea behind explicit propagation was to allow you to have > "finer" control over which operations of an object are transactional and > which are not. It's another debate entirely about whether this is actually > the right thing to do, but it's in the specification and we have to live > with it. So, if I use explicit propagation of the Control, I would not > expect to get the PropagationContext as well implicitly. Looking back over my previous emails I think I missed something out of what was transmitted (cut/paste problems again!) If you transfer the Control explicitly then you get no implicit propagation (assuming the server object isn't transactional). If the server object then calls get_txcontext and recreate itself (i.e., essentially what the implicit "filter" is doing) then there isn't any context to send back on the return from the operation, so there is no way a status can be returned. Hope this clarifies the situation. All the best, Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 24 Feb 2000 14:58:59 +0100 Message-Id: Subject: RE: Re: Re: OTS issue: PropagationContext and Status MIME-Version: 1.0 TO: M.C.Little@ncl.ac.uk, ots-rtf@omg.org CC: hanspi@adnovum.ch, urs.kuenzler@ubs.com, karsten-oliver.starr@ubs.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 24 Feb 2000 14:58:59 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Thu, 24 Feb 2000 14:58:59 +0100" X-UIDL: gg]!!`l/e9nk#!!^o$!! > > No, the implicit transaction context is transferred by the > PropagationContext, > > no matter whether implicit or explicit propagation is used. > > Not true. The propagation context is only sent if the > receiving object is > transactional. The idea behind explicit propagation was to > allow you to have > "finer" control over which operations of an object are > transactional and > which are not. It's another debate entirely about whether > this is actually > the right thing to do, but it's in the specification and we > have to live > with it. So, if I use explicit propagation of the Control, I would > not > expect to get the PropagationContext as well implicitly. > I disagree. I understand what the idea behind explicit propagation is, but it has nothing to do with the mechanism how the implicit transaction context is actually transferred. The information in the PropagationContext is useful for both propagation kinds. To me it makes most sense to have it transfered for both propagation kinds. Here are the first two paragraphs of 'Transaction Propagation'. "The transaction is represented to the application by the Control object. Within the Transaction Service, an implicit context is maintained for all threads associated with a transaction. Although there is some common information, the implicit context is not the same as the Control object defined in this specification and is distinct from the ORB Context defined by CORBA. It is the implicit context that must be transferred between execution environments to support transaction propagation. The objects using a particular Transaction Service implementation in a system form a Transaction Service domain. Within the domain, the structure and meaning of the implicit context information can be private to the implementation. When leaving the domain, this information must be translated to a common form if it is to be understood by the target Transaction Service domain, even across a single ORB. When the implicit context is transferred, it is represented as a PropagationContext." Where do you conclude from that this only refers to implicit propagation? This text only refers to transaction propagation in general and thus also applies to explicit propagation. Unless there is a text passage contradicting this, the spec requires to have the PropagationContext structure also transferred for explicit propagation. > > There are two ways > > to propagate the transaction, what OTS calls implicit and explcit > propagation. > > But there is only one transaction context transfer mechanism. > > > > In Transaction Propagation in 10.5.2 it is stated: "When the > Control > object is > > passed as an operation argument (explicit propagation), no special > transfer > > mechansim is needed." > > Yes, essentially that means that no filter/interceptor > mechanism will be > involved, since the transaction information (the Control) is > being passed as > a parameter to the invocation. > > Mark. I think that is your interpretation. Can you show me the text passage where it is written that the transaction context is not required to be transfered in the case of explicit propagation. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: "Mark Little" To: , Cc: , , References: Subject: Re: Re: Re: OTS issue: PropagationContext and Status Date: Thu, 24 Feb 2000 14:20:31 -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: a6J!!kUmd9joYd9[6Ge9 ----- Original Message ----- > I disagree. I understand what the idea behind explicit propagation is, but it > has nothing to do with the mechanism how the implicit transaction context is > actually transferred. The information in the PropagationContext is useful for > both propagation kinds. To me it makes most sense to have it transfered for > both propagation kinds. That's a different "issue" altogether ;-) Ignoring the current debate as to the removal of TransactionalObject, the current specification is very clear on the context propagation issue: (i) if the receiver is transactional (derived from TransactionalObject) then a context *must* be sent. (ii) if the receiver isn't transactional then it's implementation dependant as to what you do. This is described on page 10-13. Check page 10-10 about "Flexible transaction propagation control". Your reading of the specification would not allow this. > Where do you conclude from that this only refers to implicit propagation? The text you copy does not state that the context should be transferred on all invocations. In fact it doesn't mention when it should be transferred at all! If you need to transfer the context, then that text talks about what the actual context is to transfer. Those are two distinct issues. > This > text only refers to transaction propagation in general and thus also applies to > explicit propagation. Unless there is a text passage contradicting > this, the > spec requires to have the PropagationContext structure also > transferred for > explicit propagation. >From the pages I cite above (and from the archives on this very subject which probably stretch back several years!) I won't bother typing them in, but leave it to you to check. 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: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 24 Feb 2000 19:06:29 +0100 Message-Id: Subject: PropagationContext and Status... MIME-Version: 1.0 TO: M.C.Little@ncl.ac.uk, ots-rtf@omg.org CC: hanspi@adnovum.ch, urs.kuenzler@ubs.com, karsten-oliver.starr@ubs.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 24 Feb 2000 19:06:29 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Thu, 24 Feb 2000 19:06:29 +0100" X-UIDL: T"~e9Q*Td97Khd9d0j!! > -----Original Message----- > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > Sent: Thursday, February 24, 2000 2:36 PM > To: Hans z.h.k.k.8. Kneubuehl; ots-rtf > Cc: M.C.Little; hanspi; Urs z.h.k.g.9. Kuenzler; Karsten-Oliver > Starr > Subject: UNAUTHENTICATED: Re: Re: OTS issue: PropagationContext and > Status > > > > ----- Original Message ----- > > > IMO it is more than just a possible optimisation. It is > basic for OTS > > implementations. > > No, I disagree. Calling rollback_only simply states that the > only outcome > for the transaction is for it to rollback. The specification does > not > mandate any specific implementation for this, or that the > status from a > subordinate coordinator need be propagated back to the root > coordinator. It > does this for a reason: to let you, the implementer, find the > "right" way of > doing it for you. It's wrong to suppose there is a single > right way to do Maybe "basic" was the wrong term to express what I wanted to say. I agree that the spec does not mandate any specific implementation for this. Including the transaction status as part of the propagation context does not mandate any particular implemenation restrictions. As I wrote in my previous contribution, an OTS implementation can choose to always set the status field to StatusActive in the PropagationContext. This would be equivalent to the current specs. On the contrary, the current specs obstructs certain implementation variants. It just turns out that we have found our "right" way, but we can't make it work in the case of OTS interoperation because the standard is unnecessarly restrictive. Thus, according to your argumentation you should be in favor of this extension because it opens you, the implementor, more possibilities to find the solution that best fits you. > this: the "logical" conclusion of what you want would > actually be to say > that if the status is propagated back to the root coordinator > then it should > immediately send out an "update your status" call (or > whatever) to every > single other subordinator coordinator it knows about, simply > to stop them > doing "wasted" work. Remember, implementations may be > multi-threaded, so a > root coordinator may have many concurrent active subordinator > coordinators. > No, I don't want additional message exchange between coordinators. On the contrary, I want the OTS implementors give a possibility they can have an accurate transaction status WITHOUT additional message exchange between coordinators. > > It's just the straight way to do it. Of course, there are > > other ways to get the transaction status back to the client > OTS component. > But > > they all look just like workarounds because someone has forgotten > to > include it > > in the PropagationContext in the first place. > > I disagree that it was forgotten. If you want to accomplish > the same effect > then simply make sure your subordinator coordinator calls to the > root > coordinator when rollback_only is invoked locally. It's > simple, requires no > changes to the OTS, and is guaranteed to work on all > implementations. > It's not efficient. > > I agree that we can't call this a > > "functionality defect", but to me it is clearly a "design defect". > > > > Or, let's look at it the other way round. Are there any > drawbacks from > > including it in the PropagationContext. Even, we could allow > implementations to > > just return StatusActive with the same effect as not > returning the status. > > Probably we can't even assure that a "bad" implementation > will set the > status > > accurately. But at least, it gives the "good" OTS > implementations the > chance to > > do it. > > There are a couple of "major" disadvantages: > > (i) changing the context structure now will have a > significant effect on > existing OTS implementations and applications. They would not > interoperate > with this. > I disagree. With my proposed resolution backward compatibility is guaranteed by the specification. There would be assigend a new ServiceId assigned for the new PropagationContext_2_0. > (ii) you actually need a status for every transaction in the > hierarchy if > you support nested transactions. Just how big do you want > this context to > be? > No, I just need one transaction status to be transferred back in a reply from a transactional object invocation, namely the new status that should be associated with the implicit transaction context of the calling thread. > > > (i) send the status back in the implementation_specific_data field > > > > That's not a valid solution for standard OTS interoperation > where I am > aiming > > at. We have perfectly solved this issue for our OTS > implementation, but it > > won't work if different OTS domains are involved in the > same transaction. > > Agreed, so see my previous implementation (or the one below). > > > > > > (ii) when rollback_only is called on an interposed > > > coordinator have it call > > > the root coordinator immediately as well. > > > > > > > I can also have Current::get_status inquiring all the participating > > coordinators. It's just contrary to common sense if you can > easily have > this in > > a much cheaper and more elegant way. > > The "cheaper" and "more elegant" statements are not subjective. > I assume that you mean the "cheaper" and "more elegant" statements are not objective :-) Well, you already confirmed above that it is an optimisation. Transfering back the transaction status as part of a reply is more effecient than your solution. In case of OTS interoperation between different trx domains, your solution requires extra inter-transaction-domain-calls in order to get back the accurate transaction status to the sender side after a target invocation, but mine doesn't. Briefly, I'm proposing a backward compatible extension of the OTS that offers the possiblity for more efficient OTS interoperation and that does not impose any disadvantages, as known so far. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Date: Fri, 25 Feb 2000 06:32:28 +1000 (EST) From: Michi Henning To: hans.kneubuehl@ubs.com cc: M.C.Little@ncl.ac.uk, ots-rtf@omg.org, hanspi@adnovum.ch, urs.kuenzler@ubs.com, karsten-oliver.starr@ubs.com Subject: Re: OTS issue: PropagationContext and Status In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: PAn!!HlLd9Bg@!!f+\d9 On Thu, 24 Feb 2000 hans.kneubuehl@ubs.com wrote: > I agree that an ORB should not send any requests to transactional objects if > the transaction status is not active, although I think it is not illegal > according to the OTS spec. > > But exactly for that reason the transaction status has to be returned back as > part of the reply otherwise the local transaction component has no efficient > means to know whether e.g. the transaction has been marked for rollback. If it > is all the subsequent work by the client application will just produce useless > overhead. I agree with that. It seems utterly pointless to permit the object to mark a transaction as rolled back if there is no obvious way for the client to find out. 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 X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 24 Feb 2000 13:46:28 -0800 To: hans.kneubuehl@ubs.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org From: Edward Cobb Subject: RE: Re: Re: OTS issue: PropagationContext and Status Cc: hanspi@adnovum.ch, urs.kuenzler@ubs.com, karsten-oliver.starr@ubs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: V3A!!#7gd9=W"e96G2!! I can tell you historically that the propagation context was never intended to be passed when explicit propagation was used. Since explicit propagation was not an initial design point, I can believe that the spec might need some clarification. However, a better solution, IMHO, would be to remove explicit propagation from the sepec completely since I am not aware that anyone has proved that it can be implemented with any of the normal transaction guarantees. At 02:58 PM 2/24/00 +0100, hans.kneubuehl@ubs.com wrote: > > >> > No, the implicit transaction context is transferred by the >> PropagationContext, >> > no matter whether implicit or explicit propagation is used. >> >> Not true. The propagation context is only sent if the >> receiving object is >> transactional. The idea behind explicit propagation was to >> allow you to have >> "finer" control over which operations of an object are >> transactional and >> which are not. It's another debate entirely about whether >> this is actually >> the right thing to do, but it's in the specification and we >> have to live >> with it. So, if I use explicit propagation of the Control, I would not >> expect to get the PropagationContext as well implicitly. >> > >I disagree. I understand what the idea behind explicit propagation is, but it >has nothing to do with the mechanism how the implicit transaction context is >actually transferred. The information in the PropagationContext is useful for >both propagation kinds. To me it makes most sense to have it transfered for >both propagation kinds. > >Here are the first two paragraphs of 'Transaction Propagation'. > >"The transaction is represented to the application by the Control object. >Within the >Transaction Service, an implicit context is maintained for all threads >associated with a >transaction. Although there is some common information, the implicit context is >not >the same as the Control object defined in this specification and is distinct >from the >ORB Context defined by CORBA. It is the implicit context that must be >transferred >between execution environments to support transaction propagation. > >The objects using a particular Transaction Service implementation in a system >form a >Transaction Service domain. Within the domain, the structure and meaning of the >implicit context information can be private to the implementation. When leaving >the >domain, this information must be translated to a common form if it is to be >understood >by the target Transaction Service domain, even across a single ORB. When the >implicit >context is transferred, it is represented as a PropagationContext." > >Where do you conclude from that this only refers to implicit propagation? This >text only refers to transaction propagation in general and thus also applies to >explicit propagation. Unless there is a text passage contradicting this, the >spec requires to have the PropagationContext structure also transferred for >explicit propagation. > > >> > There are two ways >> > to propagate the transaction, what OTS calls implicit and explcit >> propagation. >> > But there is only one transaction context transfer mechanism. >> > >> > In Transaction Propagation in 10.5.2 it is stated: "When the Control >> object is >> > passed as an operation argument (explicit propagation), no special >> transfer >> > mechansim is needed." >> >> Yes, essentially that means that no filter/interceptor >> mechanism will be >> involved, since the transaction information (the Control) is >> being passed as >> a parameter to the invocation. >> >> Mark. > >I think that is your interpretation. Can you show me the text passage where it >is written that the transaction context is not required to be transfered in the >case of explicit propagation. > >Regards >Hans >-- >Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland >phone: +41 1 238 28 96, fax: +41 1 238 30 11 > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** From: "Mark Little" To: , Cc: , , References: Subject: Re: PropagationContext and Status... Date: Fri, 25 Feb 2000 09:55:39 -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: $I0e9n#7e9,C/e9C$Pe9 ----- Original Message ----- > Maybe "basic" was the wrong term to express what I wanted to say. I agree that > the spec does not mandate any specific implementation for this. > > Including the transaction status as part of the propagation context does not > mandate any particular implemenation restrictions. As I wrote in my previous > contribution, an OTS implementation can choose to always set the status field > to StatusActive in the PropagationContext. This would be equivalent to the > current specs. Except structure would have to be changed. > On the contrary, the current specs obstructs certain implementation variants. > It just turns out that we have found our "right" way, but we can't make it work > in the case of OTS interoperation because the standard is unnecessarly > restrictive. But you could make it work in a portable manner. Consider this (off the top of my head) implementation: if the client and server are your transaction services then you modify the implementation_specific_data (or possibly extend the context information in another way). If not, then you either don't bother updating the root coordinator's status, or invoke rollback_only on it directly when the subordinate coordinator is rolled back. This is guaranteed to work on all implementations. It may be sub-optimal (as far as you are concerned) if you are interacting with someone else's OTS implementation (and they don't work with your context extensions). However, you have it as an added-value feature. It's rarely the case that specifications can give everyone what they want, and if they did they'd be so unwieldy that no-one would implement them. However, the advantages of object-oriented techniques is that you can dynamically extend objects with features you require. > Thus, according to your argumentation you should be in favor of this extension > because it opens you, the implementor, more possibilities to find the solution > that best fits you. I'm against change for the sake of change. I've yet to be convinced by anything you've said that this is something that the majority of transactional applications would want, or that it can't be implemented using the current specification anyway. > No, I don't want additional message exchange between coordinators. On the > contrary, I want the OTS implementors give a possibility they can have an > accurate transaction status WITHOUT additional message exchange between > coordinators. But my argument is that the coordinators would only have an accurate status if you continually propagated it from the root to the subordinates whenever the root is informed of a change! You originally started out this thread with the statement that you wanted to prevent unnecessary work from being done once rollback_only was called. What I said (in the deleted text) was that your implementation would still not prevent that in a multi-threaded environment. > > I disagree that it was forgotten. If you want to accomplish > > the same effect > > then simply make sure your subordinator coordinator calls to the > root > > coordinator when rollback_only is invoked locally. It's > > simple, requires no > > changes to the OTS, and is guaranteed to work on all > implementations. > > > > It's not efficient. But it's not necessary! > > There are a couple of "major" disadvantages: > > > > (i) changing the context structure now will have a > > significant effect on > > existing OTS implementations and applications. They would not > > interoperate > > with this. > > > > I disagree. With my proposed resolution backward compatibility is guaranteed by > the specification. There would be assigend a new ServiceId assigned > for the new > PropagationContext_2_0. > > > (ii) you actually need a status for every transaction in the > > hierarchy if > > you support nested transactions. Just how big do you want > > this context to > > be? > > > > No, I just need one transaction status to be transferred back in a > reply from a > transactional object invocation, namely the new status that should > be > associated with the implicit transaction context of the calling > thread. Consider nested transactions. Each transaction needs it because any transaction in the hierarchy could be marked as rollback only. > > The "cheaper" and "more elegant" statements are not subjective. > > > > I assume that you mean the "cheaper" and "more elegant" statements > are not > objective :-) True ;-) > Well, you already confirmed above that it is an optimisation. Transfering back > the transaction status as part of a reply is more effecient than your solution. > In case of OTS interoperation between different trx domains, your solution > requires extra inter-transaction-domain-calls in order to get back the accurate > transaction status to the sender side after a target invocation, but mine > doesn't. That's true, but like I said is it a necessary (or important) change? Can it be accomplished for those implementations that need it without changes to the specification? Yes, and in your way if you want, and if co-operating domains agree. 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: "'Edward Cobb'" , , , Cc: , , Subject: RE: Re: Re: OTS issue: PropagationContext and Status Date: Fri, 25 Feb 2000 12:18:01 -0500 Message-ID: <000e01bf7fb4$45ccbe30$a003020a@dublin.iona.ie> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3.0.5.32.20000224134628.00965550@svlhome2.beasys.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ~-5!!D~K!!b)ld9%B5!! I'm also in favor of removing explicit context passing as preferable to clarifying it. -----Original Message----- From: Edward Cobb [mailto:ed.cobb@beasys.com] Sent: Thursday, February 24, 2000 4:46 PM To: hans.kneubuehl@ubs.com; M.C.Little@ncl.ac.uk; ots-rtf@omg.org Cc: hanspi@adnovum.ch; urs.kuenzler@ubs.com; karsten-oliver.starr@ubs.com Subject: RE: Re: Re: OTS issue: PropagationContext and Status I can tell you historically that the propagation context was never intended to be passed when explicit propagation was used. Since explicit propagation was not an initial design point, I can believe that the spec might need some clarification. However, a better solution, IMHO, would be to remove explicit propagation from the sepec completely since I am not aware that anyone has proved that it can be implemented with any of the normal transaction guarantees. At 02:58 PM 2/24/00 +0100, hans.kneubuehl@ubs.com wrote: > > >> > No, the implicit transaction context is transferred by the >> PropagationContext, >> > no matter whether implicit or explicit propagation is used. >> >> Not true. The propagation context is only sent if the >> receiving object is >> transactional. The idea behind explicit propagation was to >> allow you to have >> "finer" control over which operations of an object are >> transactional and >> which are not. It's another debate entirely about whether >> this is actually >> the right thing to do, but it's in the specification and we >> have to live >> with it. So, if I use explicit propagation of the Control, I would not >> expect to get the PropagationContext as well implicitly. >> > >I disagree. I understand what the idea behind explicit propagation is, but it >has nothing to do with the mechanism how the implicit transaction context is >actually transferred. The information in the PropagationContext is useful for >both propagation kinds. To me it makes most sense to have it transfered for >both propagation kinds. > >Here are the first two paragraphs of 'Transaction Propagation'. > >"The transaction is represented to the application by the Control object. >Within the >Transaction Service, an implicit context is maintained for all threads >associated with a >transaction. Although there is some common information, the implicit context is >not >the same as the Control object defined in this specification and is distinct >from the >ORB Context defined by CORBA. It is the implicit context that must be >transferred >between execution environments to support transaction propagation. > >The objects using a particular Transaction Service implementation in a system >form a >Transaction Service domain. Within the domain, the structure and meaning of the >implicit context information can be private to the implementation. When leaving >the >domain, this information must be translated to a common form if it is to be >understood >by the target Transaction Service domain, even across a single ORB. When the >implicit >context is transferred, it is represented as a PropagationContext." > >Where do you conclude from that this only refers to implicit propagation? This >text only refers to transaction propagation in general and thus also applies to >explicit propagation. Unless there is a text passage contradicting this, the >spec requires to have the PropagationContext structure also transferred for >explicit propagation. > > >> > There are two ways >> > to propagate the transaction, what OTS calls implicit and explcit >> propagation. >> > But there is only one transaction context transfer mechanism. >> > >> > In Transaction Propagation in 10.5.2 it is stated: "When the Control >> object is >> > passed as an operation argument (explicit propagation), no special >> transfer >> > mechansim is needed." >> >> Yes, essentially that means that no filter/interceptor >> mechanism will be >> involved, since the transaction information (the Control) is >> being passed as >> a parameter to the invocation. >> >> Mark. > >I think that is your interpretation. Can you show me the text passage where it >is written that the transaction context is not required to be transfered in the >case of explicit propagation. > >Regards >Hans >-- >Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland >phone: +41 1 238 28 96, fax: +41 1 238 30 11 > > > ************************************************************** 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: "'Michi Henning'" , Cc: , , , , Subject: RE: OTS issue: PropagationContext and Status Date: Fri, 25 Feb 2000 12:18:13 -0500 Message-ID: <000f01bf7fb4$4c6ff630$a003020a@dublin.iona.ie> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 4p I agree that an ORB should not send any requests to transactional objects if > the transaction status is not active, although I think it is not illegal > according to the OTS spec. > > But exactly for that reason the transaction status has to be returned back as > part of the reply otherwise the local transaction component has no efficient > means to know whether e.g. the transaction has been marked for rollback. If it > is all the subsequent work by the client application will just produce useless > overhead. I agree with that. It seems utterly pointless to permit the object to mark a transaction as rolled back if there is no obvious way for the client to find out. 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: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 25 Feb 2000 18:55:32 +0100 Message-Id: Subject: Re: OTS issue: PropagationContext and Status MIME-Version: 1.0 TO: ed.cobb@beasys.com, hans.kneubuehl@ubs.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org CC: hanspi@adnovum.ch, urs.kuenzler@ubs.com, karsten-oliver.starr@ubs.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 25 Feb 2000 18:55:32 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 25 Feb 2000 18:55:32 +0100" X-UIDL: #U`d9"?K!!lp#e9(Z2!! > -----Original Message----- > From: ed.cobb [mailto:ed.cobb@beasys.com] > Sent: Thursday, February 24, 2000 10:46 PM > To: Hans z.h.k.k.8. Kneubuehl; M.C.Little; ots-rtf > Cc: ed.cobb; hanspi; Urs z.h.k.g.9. Kuenzler; Karsten-Oliver Starr > Subject: UNAUTHENTICATED: RE: Re: Re: OTS issue: > PropagationContext and > Status > > > I can tell you historically that the propagation > context was never > intended to be passed when explicit propagation was used. > Since explicit > propagation was not an initial design point, I can believe > that the spec > might need some clarification. > However, a better solution, IMHO, would be to remove > explicit propagation > from the sepec completely since I am not aware that anyone > has proved that > it can be implemented with any of the normal transaction guarantees. > Ok, I accept the original intent. Thanks for the clarification and thanks to Mark for trying to convince me based on the specs. This means that trying to prove my point is pointless, but I'm convinced that there is at least one new issue. I will think about it. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Date: Mon, 28 Feb 2000 07:05:18 +1000 (EST) From: Michi Henning To: Mark Little cc: hans.kneubuehl@ubs.com, ots-rtf@omg.org, hanspi@adnovum.ch, urs.kuenzler@ubs.com, karsten-oliver.starr@ubs.com Subject: Re: Has the PropagationContext to be transferred implicitly in the case of explicit transaction propagation? In-Reply-To: <025d01bf7f74$6678a620$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ~MKd98I2!!bIL!!l#!"! On Fri, 25 Feb 2000, Mark Little wrote: > (i) transmit the context always > (ii) only transmit if the receiver is transactional > > Actually, there is a third: > > (iii) only guarantee to transmit if the receiver is transactional, > but allow > an implementation to transmit always if it wants to (which is > essentially > what the 1.1 OTS specification allows). I'm not very fond of that one because it really hampers interoperability and portability. As soon as different implementations are permitted to exhibit different behavior, developers will unwittingly assume that whatever behavior their implemention exhibits is the only one, and then get bitten if the OTS changes or the code is ported. I would still prefer to unconditionally propagate the context. The main reason is that I cannot see any other way around the problem of nested calls that go via an intermediate non-transactional object. Cheers, Michi. Date: Mon, 28 Feb 2000 07:31:25 +1000 (EST) From: Michi Henning To: Eric Newcomer cc: "'Edward Cobb'" , hans.kneubuehl@ubs.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org, hanspi@adnovum.ch, urs.kuenzler@ubs.com, karsten-oliver.starr@ubs.com Subject: RE: Re: Re: OTS issue: PropagationContext and Status In-Reply-To: <000e01bf7fb4$45ccbe30$a003020a@dublin.iona.ie> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 71P!!#F1e9^i8e9"aK!! On Fri, 25 Feb 2000, Eric Newcomer wrote: > I'm also in favor of removing explicit context passing as preferable to > clarifying it. Yes, let's get rid of it. It is not clear to me anyway whether checked transactions in combination with explicit propagation are even implementable... 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: Peter Furniss To: "'Michi Henning'" Cc: "ots-rtf@omg.org" Subject: RE: Re: Re: OTS issue: PropagationContext and Status Date: Mon, 28 Feb 2000 00:37:29 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id TAA03993 Content-Type: text/plain; charset="us-ascii" X-UIDL: "[e!!J1(!!#Nod9(8'!! Michi Henning sent : > On Fri, 25 Feb 2000, Eric Newcomer wrote: > > > I'm also in favor of removing explicit context passing as > preferable to > > clarifying it. > > Yes, let's get rid of it. It is not clear to me anyway whether > checked > transactions in combination with explicit propagation are even > implementable... Checked + explicit is surely impossible because checked effectively means the ots and the orb (in combination) will make sure the application doesn't do something silly, and explicit means the application doesn't ask them to propagate the transaction for it, so they don't know whats going on. (weeell, if they checked any object reference passed to see if it was a Control or Coordinator perhaps ..) But transactional interoperation between OTS and any other transaction system will be very difficult if explicit propagation is unsupported. And I suspect interoperation between different OTS'es will be more difficult - or is everything sufficiently fully nailed down via portable interceptors so that the mechanisms of implicit propagation will be completely consistent. As things are (have been), the existence of the explicit propagation (and especially the calls that allow switching between implicit and explicit (Current:get_control and resume )) at least give the opportunity for extracting the transaction information from one ots so you can put it back in another (and equivalently in or out of another transaction system Peter Furniss -------------------------------------- Associate Open-IT Limited 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) Email : P.Furniss@mailbox.ulcc.ac.uk From: "Mark Little" To: , , "Edward Cobb" Cc: , , References: <3.0.5.32.20000224134628.00965550@svlhome2.beasys.com> Subject: Re: Re: Re: OTS issue: PropagationContext and Status Date: Mon, 28 Feb 2000 09:51:06 -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: %O,!!V0$!!`Qo!!LC;e9 ----- Original Message ----- > I can tell you historically that the propagation context was never > intended to be passed when explicit propagation was used. Since > explicit > propagation was not an initial design point, I can believe that the > spec > might need some clarification. > However, a better solution, IMHO, would be to remove explicit > propagation > from the sepec completely since I am not aware that anyone has > proved that > it can be implemented with any of the normal transaction guarantees. I think it would be be difficult to stop it from happening anyway. The specification is (relatively) clear on the fact that checking is not possible unless you're using implicit, so I'd say "let the programmer beware", i.e., if they want to do it, then let them. This is a different point to whether or not the context is passes all of the time. All of the best, Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk From: "Mark Little" To: , "'Edward Cobb'" , , Cc: , , References: <000e01bf7fb4$45ccbe30$a003020a@dublin.iona.ie> Subject: Re: Re: Re: OTS issue: PropagationContext and Status Date: Mon, 28 Feb 2000 09:53:34 -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: ^4V!!-`De9p3gd9/N`d9 ----- Original Message ----- > I'm also in favor of removing explicit context passing as preferable to > clarifying it. I really don't think it needs clarification. If the receiving object is transactional then you'll get an implicit context (even if you decide to pass the Control as an explicit parameter). If it's not, then you won't get the context implicitly. (This obviously assumes we stick with the current specification, and don't change to making the context get propagated for every call.) Cheers, Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Mon, 28 Feb 2000 19:57:21 +1000 (EST) From: Michi Henning To: Mark Little cc: hans.kneubuehl@ubs.com, ots-rtf@omg.org, Edward Cobb , hanspi@adnovum.ch, urs.kuenzler@ubs.com, karsten-oliver.starr@ubs.com Subject: Re: Re: Re: OTS issue: PropagationContext and Status In-Reply-To: <055701bf81d1$55deb570$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: a",e9T<'e9p4F!!?$4e9 On Mon, 28 Feb 2000, Mark Little wrote: > I think it would be be difficult to stop it from happening anyway. The > specification is (relatively) clear on the fact that checking is not ^^^^^^^^^^^^^^^^^ > possible unless you're using implicit, so I'd say "let the > programmer > beware", i.e., if they want to do it, then let them. This is a > different > point to whether or not the context is passes all of the time. Hmmm... Where is this made clear? It took me quite a while to figure this out. Also, what should the behavior be for various operations if I have checked behavior and try to suspend/resume? I think there are a few holes in that area. Why not axe explicit propagation altogether? 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: , , "Edward Cobb" , , , References: Subject: Re: Re: Re: OTS issue: PropagationContext and Status Date: Mon, 28 Feb 2000 10:12:52 -0000 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 14M!!V~l!!OXOe9)>Ne9 ----- Original Message ----- From: Michi Henning To: Mark Little Cc: ; ; Edward Cobb ; ; ; Sent: Monday, February 28, 2000 9:57 AM Subject: Re: Re: Re: OTS issue: PropagationContext and Status > On Mon, 28 Feb 2000, Mark Little wrote: > > > I think it would be be difficult to stop it from happening anyway. The > > specification is (relatively) clear on the fact that checking is not > ^^^^^^^^^^^^^^^^^ > > possible unless you're using implicit, so I'd say "let the programmer > > beware", i.e., if they want to do it, then let them. This is a different > > point to whether or not the context is passes all of the time. > > Hmmm... Where is this made clear? It took me quite a while to figure this > out. Also, what should the behavior be for various operations if I have > checked behavior and try to suspend/resume? I think there are a few holes > in that area. Why not axe explicit propagation altogether? I thought it was fairly obvious from Section 10.4.4. The issue about removing explicit needs to be much more carefuly thought about. The current specification does not mandate a specific implementation of checking, and in fact states in several places that some implementations may not need it at all. Although it's possible that simply removing explicit propagation won't negate any of this, it may well do so. I think most standard implementations of the OTS will use implicit by default, but whose to say that explicit doesn't have a role. As Peter Furniss said, interoperation with non-OTS implementations may be difficult without it. I can't see any real harm in leaving it in. Let's not get this confused with the issue about whether to propagate the context on all calls or not and have two different things argued as one. 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: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Mon, 28 Feb 2000 11:22:48 +0100 Message-Id: Subject: Re: OTS issue: PropagationContext and Status MIME-Version: 1.0 TO: ed.cobb@beasys.com, eric.newcomer@iona.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org CC: hanspi@adnovum.ch, urs.kuenzler@ubs.com, karsten-oliver.starr@ubs.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Mon, 28 Feb 2000 11:22:48 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Mon, 28 Feb 2000 11:22:48 +0100" X-UIDL: 7S%!!'Z1!!"-=e95%k!! > -----Original Message----- > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > Sent: Monday, February 28, 2000 10:54 AM > I really don't think it needs clarification. If the receiving > object is > transactional then you'll get an implicit context (even if > you decide to > pass the Control as an explicit parameter). If it's not, then > you won't get > the context implicitly. Just to be precise :-), I think that you wanted to say: If the receiving object inherits from the interface TransactionalObject ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ then you'll get an implicit context. If it's not, then you won't get the context implicitly. -> There is a difference between transactional object and TransactionalObject. The term transactional object is used to refer to an object whose behavior is affected by being invoked within the scope of a transaction (see p. 10-4 of the OTS spec). An object that supports explicit transaction propagation is also a transactional object, but no inheritance from TransactionalObject is required. TransactionalObject indicates implicit transaction propagation. Thus each object that inherits TransactionalObject is a transactional object, but not vice versa. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: "Mark Little" To: , , , Cc: , , References: Subject: Re: OTS issue: PropagationContext and Status Date: Mon, 28 Feb 2000 10:34:55 -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: Y!Me9G*;!!d@4!!:'P!! ----- Original Message ----- > > I really don't think it needs clarification. If the receiving > > object is > > transactional then you'll get an implicit context (even if > > you decide to > > pass the Control as an explicit parameter). If it's not, then > > you won't get > > the context implicitly. > > Just to be precise :-), I think that you wanted to say: > If the receiving object > inherits from the interface TransactionalObject > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > then you'll get an implicit context. If it's not, > then you won't get the context implicitly. I was actually deliberately not talking about TO since this stands true for the POA based specification as well. That's why I tried to use the English-text version instead, hoping that readers would understand that it was to cover both. > -> There is a difference between transactional object and TransactionalObject. > The term transactional object is used to refer to an object whose behavior is > affected by being invoked within the scope of a transaction (see p. 10-4 of the > OTS spec). An object that supports explicit transaction propagation is also a > transactional object, but no inheritance from TransactionalObject is required. > TransactionalObject indicates implicit transaction propagation. Thus each > object that inherits TransactionalObject is a transactional object, but not > vice versa. True. My definition for this text is: "either a TransactionalObject, or resides within a transactional POA". 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: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Mon, 28 Feb 2000 14:27:49 +0100 Message-Id: Subject: Re: OTS issue: PropagationContext and Status MIME-Version: 1.0 TO: ed.cobb@beasys.com, eric.newcomer@iona.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org CC: hanspi@adnovum.ch, urs.kuenzler@ubs.com, karsten-oliver.starr@ubs.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Mon, 28 Feb 2000 14:27:49 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Mon, 28 Feb 2000 14:27:49 +0100" X-UIDL: 4[K!!K:!!!g97e9$1o!! > -----Original Message----- > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > Sent: Monday, February 28, 2000 11:35 AM > > > I really don't think it needs clarification. If the receiving > > > object is > > > transactional then you'll get an implicit context (even if > > > you decide to > > > pass the Control as an explicit parameter). If it's not, then > > > you won't get > > > the context implicitly. > > > > Just to be precise :-), I think that you wanted to say: > > If the receiving object > > inherits from the interface TransactionalObject > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > then you'll get an implicit context. If it's not, > > then you won't get the context implicitly. > > I was actually deliberately not talking about TO since this > stands true for > the POA based specification as well. That's why I tried to use the > English-text version instead, hoping that readers would > understand that it > was to cover both. > > > -> There is a difference between transactional object and > TransactionalObject. > > The term transactional object is used to refer to an object > whose behavior > is > > affected by being invoked within the scope of a transaction > (see p. 10-4 > of the > > OTS spec). An object that supports explicit transaction > propagation is > also a > > transactional object, but no inheritance from TransactionalObject > is > required. > > TransactionalObject indicates implicit transaction > propagation. Thus each > > object that inherits TransactionalObject is a transactional > object, but > not > > vice versa. > > True. My definition for this text is: "either a > TransactionalObject, or > resides within a transactional POA". > Now, I am probably splitting hairs, but that's not quite the right definition neither :-). There could be a lot of CORBA 2.3 implementations around that support POA, but don't support transaction policies. Thus in their implementation of the OTS they support implicit transaction propagation via TransactionalObject and (at least theoretically) also could support explicit transaction propagation. Therefore your definition is "either a TransactionalObject, or associated with a transaction policy". I hope this helps. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: "Mark Little" To: , , , Cc: , , References: Subject: Re: OTS issue: PropagationContext and Status Date: Mon, 28 Feb 2000 14:04:16 -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: 4g;e9' Now, I am probably splitting hairs, Somewhat! > but that's not quite the right definition > neither :-). ^^^^^^ either (sorry for hair splitting ;-) > There could be a lot of CORBA 2.3 implementations around that > support POA, but don't support transaction policies. It is my understanding that once the transaction policy goes into the POA specification then those implementations will be broken - the policy is the way it must be done. I may not have been clear enough when I sent my email. I should have stated that I was only considering such conformant implementations. > Thus in their > implementation of the OTS they support implicit transaction > propagation via > TransactionalObject and (at least theoretically) also could support explicit > transaction propagation. Therefore your definition is "either a > TransactionalObject, or associated with a transaction policy". And this leads us back to the original problem statement from Tom: such an implementation will not be possible if the specification changes as they currently stand are adopted. If you have such an implementation then it won't have access to a TransactionalObject interface in the 1.2 OTS CosTransactions module. 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: "'Peter Furniss'" , "'Michi Henning'" Cc: Subject: RE: Re: Re: OTS issue: PropagationContext and Status Date: Mon, 28 Feb 2000 10:51:42 -0500 Message-ID: <002401bf8203$b61a1a60$a085413f@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 Importance: Normal In-Reply-To: <01BF8184.185D5820@B099.ds.ulcc.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 3-%e9Pnpd9\7p!!",id9 Interoperability would seem to be possible to specify through the use of interposition and the optional 2PC protocol in the back of the spec. In other words, if we "profiled" the requirements for interoperability a little bit differently than for homogenous implementations, we could probably describe requirements that would provide interoperability without requiring explicit context propagation. Each vendor would have to support the interposition model for interoperability, and build a small "gateway" or "bridge" to map the optional 2PC protocol in the back of the spec (which I guess for interoperability purposes would then be mandated) to their own 2PC protocol (assuming, of course, that it's different, which it of course may be). The interposed OTS would also have to be able to map foreign TxIDs to local TxIDs. Eric -----Original Message----- From: Peter Furniss [mailto:p.furniss@mailbox.ulcc.ac.uk] Sent: Sunday, February 27, 2000 7:37 PM To: 'Michi Henning' Cc: ots-rtf@omg.org Subject: RE: Re: Re: OTS issue: PropagationContext and Status Michi Henning sent : > On Fri, 25 Feb 2000, Eric Newcomer wrote: > > > I'm also in favor of removing explicit context passing as preferable to > > clarifying it. > > Yes, let's get rid of it. It is not clear to me anyway whether checked > transactions in combination with explicit propagation are even implementable... Checked + explicit is surely impossible because checked effectively means the ots and the orb (in combination) will make sure the application doesn't do something silly, and explicit means the application doesn't ask them to propagate the transaction for it, so they don't know whats going on. (weeell, if they checked any object reference passed to see if it was a Control or Coordinator perhaps ..) But transactional interoperation between OTS and any other transaction system will be very difficult if explicit propagation is unsupported. And I suspect interoperation between different OTS'es will be more difficult - or is everything sufficiently fully nailed down via portable interceptors so that the mechanisms of implicit propagation will be completely consistent. As things are (have been), the existence of the explicit propagation (and especially the calls that allow switching between implicit and explicit (Current:get_control and resume )) at least give the opportunity for extracting the transaction information from one ots so you can put it back in another (and equivalently in or out of another transaction system Peter Furniss -------------------------------------- Associate Open-IT Limited 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) Email : P.Furniss@mailbox.ulcc.ac.uk Date: Tue, 29 Feb 2000 07:38:12 +1000 (EST) From: Michi Henning To: Mark Little cc: hans.kneubuehl@ubs.com, ed.cobb@beasys.com, eric.newcomer@iona.com, ots-rtf@omg.org, hanspi@adnovum.ch, urs.kuenzler@ubs.com, karsten-oliver.starr@ubs.com Subject: Re: OTS issue: PropagationContext and Status In-Reply-To: <065001bf81f4$b3b28e10$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 9i9e983[!!M~ld9eQl!! On Mon, 28 Feb 2000, Mark Little wrote: > > Thus in their > > implementation of the OTS they support implicit transaction > propagation > via > > TransactionalObject and (at least theoretically) also could > support > explicit > > transaction propagation. Therefore your definition is "either a > > TransactionalObject, or associated with a transaction policy". > > And this leads us back to the original problem statement from Tom: > such an > implementation will not be possible if the specification changes as > they > currently stand are adopted. If you have such an implementation then > it > won't have access to a TransactionalObject interface in the 1.2 OTS > CosTransactions module. Maybe I'm thick, but I honestly don't understand why. TransactionalObject is an empty interface without behavior. So, the only thing that can matter is whether or not an object inherits from TO. A new OTS implementation can still test whether or not a target object inherits from this interface, even if TO doesn't exist in the newer version of the spec. So, what's the problem? 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: OTS issue: PropagationContext and Status Date: Mon, 28 Feb 2000 21:48:01 -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: E2gd9_Of!!oDI!!>j1!! ----- Original Message ----- > > > Thus in their > > > implementation of the OTS they support implicit transaction propagation > > via > > > TransactionalObject and (at least theoretically) also could > support > > explicit > > > transaction propagation. Therefore your definition is "either a > > > TransactionalObject, or associated with a transaction policy". > > > > And this leads us back to the original problem statement from Tom: > such an > > implementation will not be possible if the specification changes > as they > > currently stand are adopted. If you have such an implementation > then it > > won't have access to a TransactionalObject interface in the 1.2 > OTS > > CosTransactions module. > > Maybe I'm thick, but I honestly don't understand > why. TransactionalObject > is an empty interface without behavior. So, the only thing that can > matter > is whether or not an object inherits from TO. A new OTS > implementation > can still test whether or not a target object inherits from this interface, > even if TO doesn't exist in the newer version of the spec. So, > what's the > problem? There's two different issues here again, and maybe we're getting things confused. The issue about new clients talking to old TO looks like it can be sorted with the is_a (or similar) you mention. The issue alluded to above was more about writing an application with the new specification that uses objects inheriting from TO - that would not be possible given the current changes since TO vanishes. Maybe I misread the original email, but I was under the impression that that was what was being described. If we remove TO from the specification, it should not be possible, or allowed, for applications to use TO, for the reasons you yourself mentioned earlier today. Agreed? 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: Tue, 29 Feb 2000 07:50:24 +1000 (EST) From: Michi Henning To: Mark Little cc: hans.kneubuehl@ubs.com, ed.cobb@beasys.com, eric.newcomer@iona.com, ots-rtf@omg.org, hanspi@adnovum.ch, urs.kuenzler@ubs.com, karsten-oliver.starr@ubs.com Subject: Re: OTS issue: PropagationContext and Status In-Reply-To: <074101bf8235$7ccf4820$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: X-a!!MAAe9R38e9B/m!! On Mon, 28 Feb 2000, Mark Little wrote: > There's two different issues here again, and maybe we're getting things > confused. The issue about new clients talking to old TO looks like it can be > sorted with the is_a (or similar) you mention. Yes. (At least, that's what I think ;-) > The issue alluded to above > was more about writing an application with the new specification > that uses > objects inheriting from TO - that would not be possible given the > current > changes since TO vanishes. Maybe I misread the original email, but I > was > under the impression that that was what was being described. If we > remove TO > from the specification, it should not be possible, or allowed, for > applications to use TO, for the reasons you yourself mentioned > earlier > today. Agreed? Agreed. But, the whole point is that we want to get rid of TO, so why would we allow new implementations to use it? It does create the forward compatibility problem I mentioned: old clients can't use new implementations. However, that's the price of progress. As far as I am concerned, TO is evil and needs to go... 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: Peter Furniss To: "'Peter Furniss'" , "'Eric Newcomer'" Cc: "ots-rtf@omg.org" Subject: RE: Re: Re: OTS issue: PropagationContext and Status Date: Tue, 29 Feb 2000 00:04:51 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id KAA03003 Content-Type: text/plain; charset="us-ascii" X-UIDL: 2?Rd9&;md9NZQd9ld4!! "Profiling" the interoperability requirements would seem to be a very good idea whatever is done with explicit propagation. The interoperable implicit requirements are more comprehensive of course, but even to have a clear statement of what is needed for interoperation with explicit would make it easier for implementations to say whether they supported it (and of course, to decide if they wanted to try). What is the minimal list ? - support recreate() with a foreign TxID and Coordinator object reference in the propagation context - use register_resource back to that Coordinator to link in - subcoordinator behaves as a normal Resource (and user of RecoveryCoordinator) There are various further things that are nice but not essential - including getting the right answer to is_same_transaction if the transaction has bridged twice in different places.(which is probably near impossible for some) Should this be a distinct issue ? Peter Furniss -------------------------------------- Associate Open-IT Limited 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) Email : P.Furniss@mailbox.ulcc.ac.uk Eric Newcomer sent : > Interoperability would seem to be possible to specify through the use of > interposition and the optional 2PC protocol in the back of the spec. In > other words, if we "profiled" the requirements for interoperability a little > bit differently than for homogenous implementations, we could probably > describe requirements that would provide interoperability without requiring > explicit context propagation. > > Each vendor would have to support the interposition model for > interoperability, and build a small "gateway" or "bridge" to map the > optional 2PC protocol in the back of the spec (which I guess for > interoperability purposes would then be mandated) to their own 2PC protocol > (assuming, of course, that it's different, which it of course may be). The > interposed OTS would also have to be able to map foreign TxIDs to local > TxIDs. > > Eric > > -----Original Message----- > From: Peter Furniss [mailto:p.furniss@mailbox.ulcc.ac.uk] > Sent: Sunday, February 27, 2000 7:37 PM > To: 'Michi Henning' > Cc: ots-rtf@omg.org > Subject: RE: Re: Re: OTS issue: PropagationContext and Status > > Michi Henning sent : > > > On Fri, 25 Feb 2000, Eric Newcomer wrote: > > > > > I'm also in favor of removing explicit context passing as preferable to > > > clarifying it. > > > > Yes, let's get rid of it. It is not clear to me anyway whether checked > > transactions in combination with explicit propagation are even > implementable... > > Checked + explicit is surely impossible because checked effectively means > the ots and the orb (in combination) will make sure the application doesn't > do something silly, and explicit means the application doesn't ask them to > propagate the transaction for it, so they don't know whats going on. > (weeell, if they checked any object reference passed to see if it was a > Control or Coordinator perhaps ..) > > But transactional interoperation between OTS and any other transaction > system will be very difficult if explicit propagation is unsupported. And I > suspect interoperation between different OTS'es will be more difficult - or > is everything sufficiently fully nailed down via portable interceptors so > that the mechanisms of implicit propagation will be completely consistent. > As things are (have been), the existence of the explicit propagation (and > especially the calls that allow switching between implicit and explicit > (Current:get_control and resume )) at least give the opportunity for > extracting the transaction information from one ots so you can put it back > in another (and equivalently in or out of another transaction system > > Peter Furniss > > -------------------------------------- > Associate > Open-IT Limited > 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK > Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) > Email : P.Furniss@mailbox.ulcc.ac.uk > > > > Reply-To: From: "Eric Newcomer" To: "'Peter Furniss'" Cc: Subject: RE: Re: Re: OTS issue: PropagationContext and Status Date: Tue, 29 Feb 2000 10:13:12 -0500 Message-ID: <001c01bf82c7$7fa2ed30$a085413f@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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <01BF8248.B52ACB00@B036.ds.ulcc.ac.uk> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: J%W!!JSd!!pj4!!_b9e9 This sounds like the list to me. I agree is same transaction would be hard to implement, might have to specify an exception condition instead if it occurs (although of course testing for it may also be problematic without explicitly defining txID formats). Yes, I think it would be good to have an issue on this. We are starting to get requests around interoperability, and it would be good to be able to point to something standard rather than just something we come up with that someone else may or may not agree with. Eric -----Original Message----- From: Peter Furniss [mailto:p.furniss@mailbox.ulcc.ac.uk] Sent: Monday, February 28, 2000 7:05 PM To: 'Peter Furniss'; 'Eric Newcomer' Cc: ots-rtf@omg.org Subject: RE: Re: Re: OTS issue: PropagationContext and Status "Profiling" the interoperability requirements would seem to be a very good idea whatever is done with explicit propagation. The interoperable implicit requirements are more comprehensive of course, but even to have a clear statement of what is needed for interoperation with explicit would make it easier for implementations to say whether they supported it (and of course, to decide if they wanted to try). What is the minimal list ? - support recreate() with a foreign TxID and Coordinator object reference in the propagation context - use register_resource back to that Coordinator to link in - subcoordinator behaves as a normal Resource (and user of RecoveryCoordinator) There are various further things that are nice but not essential - including getting the right answer to is_same_transaction if the transaction has bridged twice in different places.(which is probably near impossible for some) Should this be a distinct issue ? Peter Furniss -------------------------------------- Associate Open-IT Limited 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) Email : P.Furniss@mailbox.ulcc.ac.uk Eric Newcomer sent : > Interoperability would seem to be possible to specify through the use of > interposition and the optional 2PC protocol in the back of the spec. In > other words, if we "profiled" the requirements for interoperability a little > bit differently than for homogenous implementations, we could probably > describe requirements that would provide interoperability without requiring > explicit context propagation. > > Each vendor would have to support the interposition model for > interoperability, and build a small "gateway" or "bridge" to map the > optional 2PC protocol in the back of the spec (which I guess for > interoperability purposes would then be mandated) to their own 2PC protocol > (assuming, of course, that it's different, which it of course may be). The > interposed OTS would also have to be able to map foreign TxIDs to local > TxIDs. > > Eric > > -----Original Message----- > From: Peter Furniss [mailto:p.furniss@mailbox.ulcc.ac.uk] > Sent: Sunday, February 27, 2000 7:37 PM > To: 'Michi Henning' > Cc: ots-rtf@omg.org > Subject: RE: Re: Re: OTS issue: PropagationContext and Status > > Michi Henning sent : > > > On Fri, 25 Feb 2000, Eric Newcomer wrote: > > > > > I'm also in favor of removing explicit context passing as preferable to > > > clarifying it. > > > > Yes, let's get rid of it. It is not clear to me anyway whether checked > > transactions in combination with explicit propagation are even > implementable... > > Checked + explicit is surely impossible because checked effectively means > the ots and the orb (in combination) will make sure the application doesn't > do something silly, and explicit means the application doesn't ask them to > propagate the transaction for it, so they don't know whats going on. > (weeell, if they checked any object reference passed to see if it was a > Control or Coordinator perhaps ..) > > But transactional interoperation between OTS and any other transaction > system will be very difficult if explicit propagation is unsupported. And I > suspect interoperation between different OTS'es will be more difficult - or > is everything sufficiently fully nailed down via portable interceptors so > that the mechanisms of implicit propagation will be completely consistent. > As things are (have been), the existence of the explicit propagation (and > especially the calls that allow switching between implicit and explicit > (Current:get_control and resume )) at least give the opportunity for > extracting the transaction information from one ots so you can put it back > in another (and equivalently in or out of another transaction system > > Peter Furniss > > -------------------------------------- > Associate > Open-IT Limited > 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK > Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) > Email : P.Furniss@mailbox.ulcc.ac.uk > > > > From: "Mark Little" To: , Cc: , , References: Subject: Re: Has the PropagationContext to be transferred implicitly in the case of explicit transaction propagation? Date: Fri, 25 Feb 2000 09:40: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: 1>1e9cbMe9>B&!!\/Qe9 ----- Original Message ----- > I assume you refer to the following text: > > "The object adapter is not required to initialize the transaction context of > every request handler. It is required to initialize the transaction context of > every request only if the interface supported by the target object is derived > from the TransactionalObject interface. Otherwise, the initial transaction > context is undefined." > > Ignoring the removal of TransactionalObject, this is one point somehow backing > up your position. From this, I conclude that, prior to the changes introduced > by the messaging submission, the spec was contradictory. I would even say that, > prior to the messaging changes, the spec was wrong here. The text was not contradictory, it simply left it open for several different implementations. I have yet to hear anything from you that indicates your method is better than any other, so why should we tie down the specification to back up your implementation!? The "one-size fits all" methodology doesn't always work, and allowing flexibility in implementations is a good idea. > However, the text you are referring to refers to the receiver side, it is > saying nothing whether the PropagationContext has or has not to be marshaled on > the sender side. By the same argument it does not say it must be! In fact, throughout the document there are several places where the text explicitly states "can" be implicitly propagated. I think you will find it does not say "must always" be propagated. The whole point of explicit context propagation was to allow an individual method on an object to be transactional, while others aren't. If the context is implicitly passed all of the time, then every method could be transactional, removing the benefit of explicit propagation. The removal of TransactionalObject does not negate this. If you did not receive the flood of emails on this over the last 2 weeks then I suggest you go back and read the archive. There are still two camps: (i) transmit the context always (ii) only transmit if the receiver is transactional Actually, there is a third: (iii) only guarantee to transmit if the receiver is transactional, but allow an implementation to transmit always if it wants to (which is essentially what the 1.1 OTS specification allows). > Additionally, the above text has been changed by the Messaging submission to > > "The object adapter initializes the transaction context of the request handler > only if a > Transaction Service provided IOP::ServiceContext is present in the request > message. > Otherwise, the initial transaction context of the thread is empty because there > is no > transaction." > > Thus, at this point, this backs up my position, because using explicit > propagation there must be a transaction and thus this requires that a > ServiceContext is present. The content of the ServiceContext is clearly > defined, it's the PropagationContext data structure. > > > Check page 10-10 about "Flexible transaction propagation > > control". Your > > reading of the specification would not allow this. > > > > The pointed to location speaks about transaction propagation, not about > implicit transaction context propagation. The OTS makes a distinction between > these two. Yes, my point exactly. See above on how you can lose flexibility (and performance!) if you transmit always. > (1) "It is the implicit context that must be transferred between execution > environments to support transaction propagation." > -> This clearly states that the implicit context has to be transferred, also in > the case of explicit propagation. No it does not. What it says is: "if you want to propagate the transaction context information from one address space to another then use the PropagationContext structure: the Control information used for explicit isn't the same thing and have the same affect." > > (2) "When the implicit context is transferred, it is represented as > a > PropagationContext." > -> This clearly states that the implicit context has to be > transferred by the > PropagationContext data structure. Point 2 is not under argument, and never has been! The Control passed using explicit propagation is not the same thing as the PropagationContext. > > Now from (1) and (2) it still is not clear how the > PropagationContext structure > is transferred, whether it has to be part of the request to the > target, or not. > I can't find any statement which says this explicitly. However, in > the case the > OTS and the ORB cooperate according to the OTS as mandated in > section > "Transaction Service Portability", it is assured that the > Propagation Context > gets transferred: "A compliant ORB has to call the sender callbacks > when a > transactional operation is issued for an object in a different > project." Yes, and a transactional operation is defined either (1.1 spec) from the receiver being a TransactionalObject, or (in the new spec) from it residing within a transactional POA. Anything else and the context isn't guaranteed to be sent. > Now from this, you can argue that we have still one case where the transferal > of the PropagationContext is not mandated: If the ORB and OTS cooperate > according to a proprietary model. I suppose that this is a defect of the spec. > It cannot be the intention that OTS interoperability between different > transaction domains can depend on the mode of ORB/OTS interaction inside a > domain. It's not a defect in the specification. It clearly says when the context *must* be propagated, and that has absolutely nothing to do with the ORB/OTS implementation. No matter who you are, you *must* send the context is the receiver is transactional. No ambiguity there at all. > The pages cited above show > - that the spec, prior to the Messaging changes, has a defect for describing > the object adapapter requirements. > - you have not yet been able to provide a reference that contradicts > with the > requirement (this requirement is given in case the standard ORB OTS cooperation > model is followd) to have the PropagationContext transferred for > explicit > propagation I think I have provided sufficient. What you have not done is provided a single instance of where the specification says the context *must* always be propagated. Please do so. As further examples for my interpretation of the specification, see Sections 10.2.1, paragraph 2, 10.4.1 which describes all of the possible ways of using the transaction service, 10.4.10, 10.4.11, 10.5.2 (Requirements on the ORB), > I won't bother to go to the archives, neither :-) The standard is made up by > the spec as it stands. If the text is saying something else than the original > intent was, then this has to be raised as an issue. > > But maybe someone else could back up your position about what the original > intent was with the PropagationContext in case of explicit transaction > propagation. Yes, it would be nice to hear from others who have existing implementations. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Mon, 28 Feb 2000 07:05:18 +1000 (EST) From: Michi Henning To: Mark Little cc: hans.kneubuehl@ubs.com, ots-rtf@omg.org, hanspi@adnovum.ch, urs.kuenzler@ubs.com, karsten-oliver.starr@ubs.com Subject: Re: Has the PropagationContext to be transferred implicitly in the case of explicit transaction propagation? In-Reply-To: <025d01bf7f74$6678a620$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ~MKd98I2!!bIL!!l#!"! On Fri, 25 Feb 2000, Mark Little wrote: > (i) transmit the context always > (ii) only transmit if the receiver is transactional > > Actually, there is a third: > > (iii) only guarantee to transmit if the receiver is transactional, > but allow > an implementation to transmit always if it wants to (which is > essentially > what the 1.1 OTS specification allows). I'm not very fond of that one because it really hampers interoperability and portability. As soon as different implementations are permitted to exhibit different behavior, developers will unwittingly assume that whatever behavior their implemention exhibits is the only one, and then get bitten if the OTS changes or the code is ported. I would still prefer to unconditionally propagate the context. The main reason is that I cannot see any other way around the problem of nested calls that go via an intermediate non-transactional object. Cheers, Michi. From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Mon, 28 Feb 2000 18:33:14 +0100 Message-Id: Subject: Status in PropagationContext helps to avoid pointless invocations MIME-Version: 1.0 TO: ots-rtf@omg.org CC: derek@ooc.com.au Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Mon, 28 Feb 2000 18:33:14 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Mon, 28 Feb 2000 18:33:14 +0100" X-UIDL: !Q>!!E&Ge95fC!!S@Me9 There is another reason that associating the transaction status with the propagation context is useful. If a transaction is marked for rollback, any further invocations to transactional targets as part of the same transaction are pointless. However, how can this be avoided, in case that the ORB A is from one vendor and the OTS B from another, both cooperating according to OTS interposition? -> According to the proposed resolution below, an ORB could check the status of the current transaction in the PropagationContext_2_0 received from a sender callback and then raise a system exception if the satus is StatusMarkedRollback. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 > -----Original Message----- > From: Hans z.h.k.k.8. Kneubuehl > Sent: Tuesday, February 22, 2000 2:01 PM > I would like to raise a new OTS issue: > OTS interoperation does specify no way how the transaction > status can be propagated with a request and a reply. The > PropagationContext is missing information about the > transaction status. However, this information is essential > for efficient and accurate interoperation between different > OTS interoperation, and thus, the OTS should be corrected to > propagate this information for interoperation. > proposed resolution: > -------------------- > - introduce a new ServiceId TransactionService_2_0 in chapter > 13 of CORBA > - define a new propagation context > struct PropagationContext_2_0 > { > unsigned long timeout; > TransIdentity current; > sequence parents; > Status current_status; > any implementation_specific_data; > }; > - extend the Sender and Receiver interfaces with new > operations that support the new propagation context From: "Mark Little" To: , Cc: References: Subject: Re: Status in PropagationContext helps to avoid pointless invocations Date: Mon, 28 Feb 2000 18:19: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: Cn:e90#5!!Z$P!!)+I!! ----- Original Message ----- > There is another reason that associating the transaction status with the > propagation context is useful. If a transaction is marked for rollback, any > further invocations to transactional targets as part of the same transaction > are pointless. However, how can this be avoided, in case that the ORB A is from > one vendor and the OTS B from another, both cooperating according to OTS > interposition? How about throwing an exception at the server just before returning? That way the propagation context doesn't need to get remarshalled at the server side just to be "ignored" at the client. Surely this is a more efficient way of accomplishing what you want? 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: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Tue, 29 Feb 2000 11:18:45 +0100 Message-Id: Subject: Re: Status in PropagationContext helps to avoid pointless invocations MIME-Version: 1.0 TO: M.C.Little@ncl.ac.uk, ots-rtf@omg.org CC: derek@ooc.com.au Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Tue, 29 Feb 2000 11:18:44 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Tue, 29 Feb 2000 11:18:44 +0100" X-UIDL: 3XLe9R5[!!\D[d9"e4e9 > -----Original Message----- > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > Sent: Monday, February 28, 2000 7:20 PM > > There is another reason that associating the transaction > status with the > > propagation context is useful. If a transaction is marked > for rollback, > any > > further invocations to transactional targets as part of the same > transaction > > are pointless. However, how can this be avoided, in case > that the ORB A is > from > > one vendor and the OTS B from another, both cooperating > according to OTS > > interposition? > > How about throwing an exception at the server just before > returning? That > way the propagation context doesn't need to get remarshalled > at the server > side just to be "ignored" at the client. Surely this is a > more efficient way > of accomplishing what you want? No, that was not my point. I was referring to the client that is about to send a request to a transactional target as part of a transaction which is already marked for rollback. If the ORB gets the information from the OTS that the transaction is marked for rollback, then it can immediately return a system exception to the application without invoking the target. The OTS cooperation model specifies that the ORB calls Sender::sending_request on the OTS and gets back the PropagationContext which does not include the transaction status currently. However, according to the OTS cooperation model the OTS only registers the sender and receiver callback objects using the interface TSIdentification provided by the ORB. Thus, when just relying on the OTS cooperation model, I don't see any way how the ORB could find out that the transaction has been marked for rollback if a request is about to be sent. -> Therefore, according to my proposal, if a request is about to be sent, an ORB could check the status of the current transaction in the PropagationContext_2_0 received from calling the extended sender callback (e.g. by Sender::sending_request_2_0) and then raise a system exception if the status is StatusMarkedRollback. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: "Mark Little" To: , Cc: References: Subject: Re: Status in PropagationContext helps to avoid pointless invocations Date: Tue, 29 Feb 2000 10:38:20 -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: 6R+e9Z/Pe9Q9]!!YT1!! ----- Original Message ----- > > How about throwing an exception at the server just before > > returning? That > > way the propagation context doesn't need to get remarshalled > > at the server > > side just to be "ignored" at the client. Surely this is a > > more efficient way > > of accomplishing what you want? > > No, that was not my point. I was referring to the client that is > about to send > a request to a transactional target as part of a transaction which > is already > marked for rollback. Ah, we're at crossed purposes again. I felt sure you started out arguing from the server side. No matter. > If the ORB gets the information from the OTS that the > transaction is marked for rollback, then it can immediately return a system > exception to the application without invoking the target. I believe this may be a none issue given that TSIdentification is being dropped in favour of POI. > > The OTS cooperation model specifies that the ORB calls Sender::sending_request > on the OTS and gets back the PropagationContext which does not > include the > transaction status currently. However, according to the OTS > cooperation model > the OTS only registers the sender and receiver callback objects > using the > interface TSIdentification provided by the ORB. Thus, when just > relying on the > OTS cooperation model, I don't see any way how the ORB could find > out that the > transaction has been marked for rollback if a request is about to be > sent. I agree that with TSIdentification there is indeed an issue for the client. However, I think it may go away with POI. If it doesn't then we should address it. Though whether this requires a modification to the PropagationContext or, for example, saying that get_txcontext should throw an exception if the transaction is marked for rollback, is another question. I think there are several options available at the client that don't require changing the on-the-wire format of the PropagationContext. All the best, Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 2 Mar 2000 11:02:53 +0100 Message-Id: Subject: Re: Status in PropagationContext helps to avoid pointless invocations MIME-Version: 1.0 TO: M.C.Little@ncl.ac.uk, ots-rtf@OMG.ORG CC: derek@ooc.com.au Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 2 Mar 2000 11:02:53 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Thu, 2 Mar 2000 11:02:53 +0100" X-UIDL: Lh`!!^6K!!Vikd96bP!! > -----Original Message----- > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > Sent: Tuesday, February 29, 2000 11:38 AM > > No, that was not my point. I was referring to the client > that is about to > send > > a request to a transactional target as part of a > transaction which is > already > > marked for rollback. > > If the ORB gets the information from the OTS that the > > transaction is marked for rollback, then it can immediately return > a > system > > exception to the application without invoking the target. > > I believe this may be a none issue given that > TSIdentification is being > dropped in favour of POI. It is a none-issue with Portable Interceptors. I've verified it in the specification. The OTS registers an interceptor that is called at the send_request interception point. The OTS interceptor may raise a system exception if the transaction is marked for rollback and this will prevent the pointless invocation. (Unnice: the example Transaction Service Interceptors provided by the POI specs, do not show this... :-() > > The OTS cooperation model specifies that the ORB calls > Sender::sending_request > > on the OTS and gets back the PropagationContext which does > not include the > > transaction status currently. However, according to the OTS > cooperation > model > > the OTS only registers the sender and receiver callback > objects using the > > interface TSIdentification provided by the ORB. Thus, when > just relying on > the > > OTS cooperation model, I don't see any way how the ORB > could find out that > the > > transaction has been marked for rollback if a request is > about to be sent. > > I agree that with TSIdentification there is indeed an issue > for the client. > However, I think it may go away with POI. If it doesn't then we > should > address it. Yes, it goes away with POI (see above). However, we have to be conscious that there is also the small window between changes introduced by an OTS RTF get published and the changes from the POI spec getting published. > Though whether this requires a modification to the > PropagationContext or, for example, saying that get_txcontext > should throw > an exception if the transaction is marked for rollback, is > another question. > I think there are several options available at the client > that don't require > changing the on-the-wire format of the PropagationContext. I insist on this one: my proposal does not change the on-the-wire-format of the PropagationContext. I propose to introduce an additional data structure PropagationContext_2_0 that can coexist with PropagationContext. OTS implementations are free to provide both in their requests. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11> Date: Fri, 3 Mar 2000 06:39:09 +1000 (EST) From: Michi Henning To: hans.kneubuehl@ubs.com cc: M.C.Little@ncl.ac.uk, ots-rtf@OMG.ORG, derek@ooc.com.au Subject: Re: Status in PropagationContext helps to avoid pointless invocations In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: =7md9B#Vd9T+2!!`K(e9 On Thu, 2 Mar 2000 hans.kneubuehl@ubs.com wrote: > I insist on this one: my proposal does not change the on-the-wire-format of the > PropagationContext. I propose to introduce an additional data structure > PropagationContext_2_0 that can coexist with PropagationContext. OTS > implementations are free to provide both in their requests. We yet again hit the problem that there is no versioning information at the beginning of the context, making it near impossible to add things over time... :-( 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: Mon, 28 Feb 2000 15:33:39 -0800 To: Michi Henning , Mark Little From: Edward Cobb Subject: Re: Has the PropagationContext to be transferred implicitly in the case of explicit transaction propagation? Cc: hans.kneubuehl@ubs.com, ots-rtf@omg.org, hanspi@adnovum.ch, urs.kuenzler@ubs.com, karsten-oliver.starr@ubs.com In-Reply-To: References: <025d01bf7f74$6678a620$6e96f080@ncl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: p$W!!cpIe9@fN!!~ojd9 I'm inclined to agree with Michi. At 07:05 AM 2/28/00 +1000, Michi Henning wrote: >On Fri, 25 Feb 2000, Mark Little wrote: > >> (i) transmit the context always >> (ii) only transmit if the receiver is transactional >> >> Actually, there is a third: >> >> (iii) only guarantee to transmit if the receiver is transactional, but allow >> an implementation to transmit always if it wants to (which is essentially >> what the 1.1 OTS specification allows). > >I'm not very fond of that one because it really hampers interoperability >and portability. As soon as different implementations are permitted to >exhibit different behavior, developers will unwittingly assume that whatever >behavior their implemention exhibits is the only one, and then get bitten >if the OTS changes or the code is ported. > >I would still prefer to unconditionally propagate the context. The main >reason is that I cannot see any other way around the problem of nested >calls that go via an intermediate non-transactional object. > > Cheers, > > Michi. > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Tue, 29 Feb 2000 09:05:59 +0100 Message-Id: Subject: intermediate non-transactional object MIME-Version: 1.0 TO: ed.cobb@beasys.com, michi@ooc.com.au CC: ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Tue, 29 Feb 2000 09:05:59 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Tue, 29 Feb 2000 09:05:59 +0100" X-UIDL: )Xd!!iYad9YY_!!%`F!! > -----Original Message----- > From: michi [mailto:michi@ooc.com.au] > Sent: Sunday, February 27, 2000 10:05 PM > I would still prefer to unconditionally propagate the > context. The main > reason is that I cannot see any other way around the problem of > nested > calls that go via an intermediate non-transactional object. I don't think that intermediate non-transactional objects should be supported as part of a chain of transactional objects. This breaks the idea of objects providing a service contract and of transaction policies being part of this contract. An object offers its clients a service. The service has a signature defined by an IDL interface and exhibits some behavior. The clients must not care whether the exhibited behavior is implemented directly by the object or by doing nested calls. All exhibited behavior is just part of service contract between the client and the object. Let's assume that there is an intermediate object whose behavior, from the implementor's point of view, is not affected by a current transaction, but it does nested calls to a transactional object which can affect the status of the current transaction, e.g. mark the transaction for rollback. This transactional behavior is visible to the client of the intermediate object, but just as a result of using the service offered by the intermediate object. It does not care that the transactional behavior results from a nested call. For it, it is the intermediate object that is exhibiting transactional behavior and thus, from the user's point of view, the intermediate object is transactional. Therefore, from the client's point of view, something like an intermediate non-transactional object simply doesn't exist. The idea of transaction policies is to provide a mechanism to precisely control what transactional behavior is exhibited to the clients of an object. It's the responsiblity of the intermediate object how it implements the behavior exhibited in the service contract. If it does nested calls to transactional objects, then it appears itself as a transactional object to its clients, and thus it must also signal this by the appropriate transaction policy part of its IOR. Or, the other way round, an intermediate object can appear to its clients only as non-transactional if all of its nested calls are just calls to non-transactional objects. It should signal this by the non-transactional transaction policies (allows_none) or by the absence of a transaction policy in its IOR. In this case propagation of the transaction context is pointless, and transaction policies offer a mechanism to relief the client from having to send it with the request. Of course, an object can appear to its clients that is only transactional for certain requests based on the input arguments or based on the date and time. This behavior cannot be explicitly specified by transactional policies. They are too coarse-grained. In this case, the transaction policy must define the generalization of the behavior exhibited by the object. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Date: Wed, 1 Mar 2000 07:00:21 +1000 (EST) From: Michi Henning To: hans.kneubuehl@ubs.com cc: ed.cobb@beasys.com, ots-rtf@omg.org Subject: Re: intermediate non-transactional object In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: _&D!!*Npd99i9!!EdM!! On Tue, 29 Feb 2000 hans.kneubuehl@ubs.com wrote: > Let's assume that there is an intermediate object whose behavior, from > the implementor's point of view, is not affected by a current > transaction, but it does nested calls to a transactional object which > can affect the status of the current transaction, e.g. mark the > transaction for rollback. This transactional behavior is visible to the > client of the intermediate object, but just as a result of using the > service offered by the intermediate object. It does not care that the > transactional behavior results from a nested call. For it, it is the > intermediate object that is exhibiting transactional behavior and thus, > from the user's point of view, the intermediate object is transactional. > > Therefore, from the client's point of view, something like an > intermediate non-transactional object simply doesn't exist. > > The idea of transaction policies is to provide a mechanism to precisely > control what transactional behavior is exhibited to the clients of an > object. It's the responsiblity of the intermediate object how it > implements the behavior exhibited in the service contract. If it does > nested calls to transactional objects, then it appears itself as a > transactional object to its clients, and thus it must also signal this > by the appropriate transaction policy part of its IOR. > > Or, the other way round, an intermediate object can appear to its > clients only as non-transactional if all of its nested calls are just > calls to non-transactional objects. It should signal this by the > non-transactional transaction policies (allows_none) or by the absence > of a transaction policy in its IOR. In this case propagation of the > transaction context is pointless, and transaction policies offer a > mechanism to relief the client from having to send it with the request. > > Of course, an object can appear to its clients that is only > transactional for certain requests based on the input arguments or based > on the date and time. This behavior cannot be explicitly specified by > transactional policies. They are too coarse-grained. In this case, the > transaction policy must define the generalization of the behavior > exhibited by the object. The scenario I have in mind occurs whenever there is a nested call or, most commonly, whenever a callback is made. For example, a trader may have dynamic properties. A lookup on a trader made from within a transaction will therefore be non-transactional. The trader in turn will call out to various objects that are part of its dynamic service offers to determine a match. Some of these objects may be in the same transaction as the client doing the lookup, some of these objects may be in transactions that were started by other clients, and some be in no transaction. The trader can now either propagate the transaction context through for the evaluation of the dynamic property or not: - If it doesn't propagate the context and objects refuse to evaluate unless there is a context, the trader doesn't work at all because dynamic properties cannot be evaluated. - If it doesn't propagate the context and objects permit evaluation without a context, the behavior depends on whether the object starts a new transaction or not: - If it starts a new transaction, we get instant deadlock if the evaluation hits an object that was in the original transaction - If it doesn't start a new transaction and the evaluation hits an object that is currently in some other transaction, the evaluation proceeds by using uncommitted inconsistent state. On the other hand, if we state that non-transactional objects when called with a context must pass that same context downstream, the problems go away. You can construct similar deadlock and nonsense evaluation scenarios for anything that uses callbacks (events, notifications) and anything that uses some other object to perform a supplementary service. The behavior we get by not propagating the context unconditionally and forcing intermediate objects to pass it on appears unacceptable. It's completely useless, resulting either in complete incorrect computations or in deadlock. 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 Sender: jon@corvette.floorboard.com Message-ID: <38BD4181.B938F594@floorboard.com> Date: Wed, 01 Mar 2000 08:12:49 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: hans.kneubuehl@ubs.com, ed.cobb@beasys.com, ots-rtf@omg.org Subject: Re: intermediate non-transactional object References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: )on!!>,Sd92gBe9C;%!! Michi Henning wrote: > On the other hand, if we state that non-transactional objects when > called > with a context must pass that same context downstream, the problems > go away. > > You can construct similar deadlock and nonsense evaluation scenarios > for > anything that uses callbacks (events, notifications) and anything > that uses > some other object to perform a supplementary service. > > The behavior we get by not propagating the context unconditionally > and forcing > intermediate objects to pass it on appears unacceptable. It's > completely > useless, resulting either in complete incorrect computations or in > deadlock. The problem with this is that you are now mandating behavior in ORB implementations that may not otherwise have any support for the OTS by requiring them to recognize and propagate OTS service contexts. Besides, if that ORB doesn't support OTS, it wouldn't know enough to understand the transactional policies embedded in IORs in order to start a transaction anyway. I think your trader example is contrived, and perhaps should be held up as an example how not to architect a solution. :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org