Issue 3943: CosTransactions::Control and implicit propagation implementations (ots-rtf) Source: DSTC (Mr. Ted McFadden, mcfadden(at)dstc.edu.au) Nature: Uncategorized Issue Severity: Summary: This is in regard to CosTransactions::Control and some of the constraints it seems to place on implicit propagation implementations. I'll describe the issue in the context of an example where process A initiates a transaction and then makes a call to an object on process B which registers a resource and does some work. For example: Process A: current -> begin(); obj_on_B -> register_txn_resource_and_do_some_work(); ... [OTS-runtime attaches service context containing propagation context to request] Process B: [OTS-runtime associates invocation thread with propagation context] register_txn_resource_and_do_some_work() { ctrl = current -> get_control(); coord = ctrl -> get_coordinator(); coord -> register_resource(....) .... } This looks ok on the surface, but for an OTS implementation get_control() is not without complications: 1. If Process B uses interposition, then it simply `recreates' the transaction and returns the interposed control. But interposition is not, and shouldn't be, a required method of implementation. 2. The ots implementation can pass the control it received when originally creating the transaction around in the implementation_specific_any of the propagation context. But then multi-vendor interoperability goes out the window. Although the mere existence of implementation_specific_any suggests that it already has. ;-) 3. The ots runtime in Process B can create an in-process, non-interposed, control to front for the coord/terminator and return that. Although there is some appeal to this approach, it has some drawbacks. In addition to now requiring process B to become a server, there are lifecycle and scope concerns for this locally manufactured `control'. 4. Completely proprietary method of obtaining a control. None of these are attractive alternatives considering the propagation context delivered to process B already has the desired coordinator and terminator references. Unfortunately these can only be accessed through an `artificial' control object. I would suggest that Control might have been better off defined as a struct: struct transaction_control { Terminator term; Coordinator coord; }; If Current had an operation such as: transaction_control get_txn_control_struct(); [actual signature may vary.....] There would be no scope, or lifecycle issues with `control' and no forced use of implementation_specific_any or interposition. (I also realize there may be some resistance to introducing this type of change in an rtf, so its only one of the possible solutions listed below.) In summary, I'm asking the rtf to consider: 1. Whether the Current methods that use control are unecessarily forcing implementations to interpose, use implementation_specific_any, create local, non-interposed controls or other proprietary solutions. Some possible solutions: A. Provide: Current::getCoordinator(), Current::getTerminator() so that at least in many cases the ots runtime doesn't always have to obtain a control object to provide what it already knows. There are no versioning issues with Current since it is locality constrained. (When and if Current::get_control() is called, the ots can obtain the control reference at that point. It may still have to use interposition to do this, but it can now be avoided some of the time.) B. Provide a struct representation of Control, and corresponding operations on Current. The operations that would need `struct' equivalent are: get_control() suspend() resume() C. Pass the control explicitly in the propagation_context. (This would then possibly make a remote call to get coordinator and terminator references that are already known locally.) Solution A is a workable solution for an rtf, Solution B addresses the issue more completely, and C well, I wouldn't vote for it. Comments, Opinions? Is Control as an object providing real value or is it just a struct in disguise complicating implementations? Resolution: Revised Text: Actions taken: October 9, 2000: received issue Discussion: End of Annotations:===== Date: Mon, 9 Oct 2000 13:42:47 +1000 From: Ted McFadden To: issues@omg.org, ots-rtf@omg.org Subject: Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001009134246.B786@ooc.com.au> Mail-Followup-To: issues@omg.org, ots-rtf@omg.org Mime-Version: 1.0 X-Mailer: Mutt 1.0i Content-Type: text/plain; charset=us-ascii X-UIDL: :<_!!?iMe92Bpd9NMnd9 Hi, Now that 3425 has ceased to take all available OTS bandwidth, I'd like to raise an issue. :-) This is in regard to CosTransactions::Control and some of the constraints it seems to place on implicit propagation implementations. I'll describe the issue in the context of an example where process A initiates a transaction and then makes a call to an object on process B which registers a resource and does some work. For example: Process A: current -> begin(); obj_on_B -> register_txn_resource_and_do_some_work(); ... [OTS-runtime attaches service context containing propagation context to request] Process B: [OTS-runtime associates invocation thread with propagation context] register_txn_resource_and_do_some_work() { ctrl = current -> get_control(); coord = ctrl -> get_coordinator(); coord -> register_resource(....) .... } This looks ok on the surface, but for an OTS implementation get_control() is not without complications: 1. If Process B uses interposition, then it simply `recreates' the transaction and returns the interposed control. But interposition is not, and shouldn't be, a required method of implementation. 2. The ots implementation can pass the control it received when originally creating the transaction around in the implementation_specific_any of the propagation context. But then multi-vendor interoperability goes out the window. Although the mere existence of implementation_specific_any suggests that it already has. ;-) 3. The ots runtime in Process B can create an in-process, non-interposed, control to front for the coord/terminator and return that. Although there is some appeal to this approach, it has some drawbacks. In addition to now requiring process B to become a server, there are lifecycle and scope concerns for this locally manufactured `control'. 4. Completely proprietary method of obtaining a control. None of these are attractive alternatives considering the propagation context delivered to process B already has the desired coordinator and terminator references. Unfortunately these can only be accessed through an `artificial' control object. I would suggest that Control might have been better off defined as a struct: struct transaction_control { Terminator term; Coordinator coord; }; If Current had an operation such as: transaction_control get_txn_control_struct(); [actual signature may vary.....] There would be no scope, or lifecycle issues with `control' and no forced use of implementation_specific_any or interposition. (I also realize there may be some resistance to introducing this type of change in an rtf, so its only one of the possible solutions listed below.) In summary, I'm asking the rtf to consider: 1. Whether the Current methods that use control are unecessarily forcing implementations to interpose, use implementation_specific_any, create local, non-interposed controls or other proprietary solutions. Some possible solutions: A. Provide: Current::getCoordinator(), Current::getTerminator() so that at least in many cases the ots runtime doesn't always have to obtain a control object to provide what it already knows. There are no versioning issues with Current since it is locality constrained. (When and if Current::get_control() is called, the ots can obtain the control reference at that point. It may still have to use interposition to do this, but it can now be avoided some of the time.) B. Provide a struct representation of Control, and corresponding operations on Current. The operations that would need `struct' equivalent are: get_control() suspend() resume() C. Pass the control explicitly in the propagation_context. (This would then possibly make a remote call to get coordinator and terminator references that are already known locally.) Solution A is a workable solution for an rtf, Solution B addresses the issue more completely, and C well, I wouldn't vote for it. Comments, Opinions? Is Control as an object providing real value or is it just a struct in disguise complicating implementations? Cheers, Ted -- Ted McFadden tmcf@ooc.com.au Object Oriented Concepts http://www.ooc.com Suite 4 904 Stanley St. +61-7-3891-5744 East Brisbane 4169, QLD. Australia From: "Bernard Normier" To: "Ted McFadden" , , References: <20001009134246.B786@ooc.com.au> Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Date: Mon, 9 Oct 2000 09:53:29 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Type: text X-UIDL: Chgd9naRd9dCNe9eL9e9 Hi Ted, I agree that Control should really be a struct ... I'd vote for your B solution. Cheers, Bernard ----- Original Message ----- From: "Ted McFadden" To: ; Sent: Sunday, October 08, 2000 11:42 PM Subject: Issue with CosTransactions::Control and implicit propagation implementations > Hi, > > Now that 3425 has ceased to take all available OTS bandwidth, I'd >like > to raise an issue. :-) > > This is in regard to CosTransactions::Control and some of the > constraints it seems to place on implicit propagation >implementations. > > I'll describe the issue in the context of an example where process A > initiates a transaction and then makes a call to an object on >process > B which registers a resource and does some work. > > For example: > > Process A: > current -> begin(); > obj_on_B -> register_txn_resource_and_do_some_work(); > ... > > [OTS-runtime attaches service context containing propagation > context to request] > > Process B: > > [OTS-runtime associates invocation thread with propagation context] > > register_txn_resource_and_do_some_work() > { > ctrl = current -> get_control(); > coord = ctrl -> get_coordinator(); > coord -> register_resource(....) > .... > } > > This looks ok on the surface, but for an OTS implementation > get_control() is not without complications: > > 1. If Process B uses interposition, then it simply `recreates' the > transaction and returns the interposed control. But interposition is > not, and shouldn't be, a required method of implementation. > > 2. The ots implementation can pass the control it received when > originally creating the transaction around in the > implementation_specific_any of the propagation context. > > But then multi-vendor interoperability goes out the window. Although > the mere existence of implementation_specific_any suggests that it > already has. ;-) > > 3. The ots runtime in Process B can create an in-process, > non-interposed, control to front for the coord/terminator and return > that. Although there is some appeal to this approach, it has some > drawbacks. In addition to now requiring process B to become a >server, > there are lifecycle and scope concerns for this locally manufactured > `control'. > > 4. Completely proprietary method of obtaining a control. > > None of these are attractive alternatives considering the >propagation > context delivered to process B already has the desired coordinator >and > terminator references. Unfortunately these can only be accessed > through an `artificial' control object. > > I would suggest that Control might have been better off defined as a > struct: > > struct transaction_control { > Terminator term; > Coordinator coord; > }; > > If Current had an operation such as: > > transaction_control get_txn_control_struct(); > > [actual signature may vary.....] > > There would be no scope, or lifecycle issues with `control' and no > forced use of implementation_specific_any or interposition. (I also > realize there may be some resistance to introducing this type of > change in an rtf, so its only one of the possible solutions listed > below.) > > > In summary, I'm asking the rtf to consider: > > 1. Whether the Current methods that use control are unecessarily > forcing implementations to interpose, use >implementation_specific_any, > create local, non-interposed controls or other proprietary >solutions. > > Some possible solutions: > > A. Provide: > Current::getCoordinator(), > Current::getTerminator() > > so that at least in many cases the ots runtime doesn't always > have to obtain a control object to provide what it already > knows. There are no versioning issues with Current since it >is > locality constrained. > > (When and if Current::get_control() is called, the ots can > obtain the control reference at that point. It may still have > to use interposition to do this, but it can now be avoided >some > of the time.) > > B. Provide a struct representation of Control, and corresponding > operations on Current. > > The operations that would need `struct' equivalent are: > get_control() > suspend() > resume() > > C. Pass the control explicitly in the propagation_context. (This >would then > possibly make a remote call to get coordinator and terminator > references that are already known locally.) > > Solution A is a workable solution for an rtf, Solution B addresses >the > issue more completely, and C well, I wouldn't vote for it. > > Comments, Opinions? Is Control as an object providing real value or >is > it just a struct in disguise complicating implementations? > > > Cheers, > > Ted > > -- > Ted McFadden tmcf@ooc.com.au > Object Oriented Concepts http://www.ooc.com > Suite 4 904 Stanley St. +61-7-3891-5744 > East Brisbane 4169, QLD. Australia > Date: Tue, 10 Oct 2000 10:44:28 -0700 From: Blake Biesecker To: Bernard Normier Cc: Ted McFadden , ots-rtf@omg.org Subject: 3943 - Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001010104428.A21867@gemstone.com> References: <20001009134246.B786@ooc.com.au> <000d01c031f8$528c7100$4985413f@boston.amer.iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <000d01c031f8$528c7100$4985413f@boston.amer.iona.com>; from bernard.normier@iona.com on Mon, Oct 09, 2000 at 09:53:29AM -0400 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: #]`!!m&'!!\l4e9m=*e9 If we were starting from scratch I would agree but I'm concerned that this is dramatic change and might be to significant for an RTF. For that reason, I think A is more reasonable. Do others think we can reasonably adopt B? Blake On Mon, Oct 09, 2000 at 09:53:29AM -0400, Bernard Normier wrote: > Hi Ted, > > I agree that Control should really be a struct ... I'd vote for your B > solution. > > Cheers, > > Bernard > > ----- Original Message ----- > From: "Ted McFadden" > To: ; > Sent: Sunday, October 08, 2000 11:42 PM > Subject: Issue with CosTransactions::Control and implicit propagation > implementations > > > > Hi, > > > > Now that 3425 has ceased to take all available OTS bandwidth, I'd like > > to raise an issue. :-) > > > > This is in regard to CosTransactions::Control and some of the > > constraints it seems to place on implicit propagation implementations. > > > > I'll describe the issue in the context of an example where process A > > initiates a transaction and then makes a call to an object on process > > B which registers a resource and does some work. > > > > For example: > > > > Process A: > > current -> begin(); > > obj_on_B -> register_txn_resource_and_do_some_work(); > > ... > > > > [OTS-runtime attaches service context containing propagation > > context to request] > > > > Process B: > > > > [OTS-runtime associates invocation thread with propagation > context] > > > > register_txn_resource_and_do_some_work() > > { > > ctrl = current -> get_control(); > > coord = ctrl -> get_coordinator(); > > coord -> register_resource(....) > > .... > > } > > > > This looks ok on the surface, but for an OTS implementation > > get_control() is not without complications: > > > > 1. If Process B uses interposition, then it simply `recreates' the > > transaction and returns the interposed control. But interposition is > > not, and shouldn't be, a required method of implementation. > > > > 2. The ots implementation can pass the control it received when > > originally creating the transaction around in the > > implementation_specific_any of the propagation context. > > > > But then multi-vendor interoperability goes out the window. Although > > the mere existence of implementation_specific_any suggests that it > > already has. ;-) > > > > 3. The ots runtime in Process B can create an in-process, > > non-interposed, control to front for the coord/terminator and return > > that. Although there is some appeal to this approach, it has some > > drawbacks. In addition to now requiring process B to become a server, > > there are lifecycle and scope concerns for this locally manufactured > > `control'. > > > > 4. Completely proprietary method of obtaining a control. > > > > None of these are attractive alternatives considering the propagation > > context delivered to process B already has the desired coordinator and > > terminator references. Unfortunately these can only be accessed > > through an `artificial' control object. > > > > I would suggest that Control might have been better off defined as a > > struct: > > > > struct transaction_control { > > Terminator term; > > Coordinator coord; > > }; > > > > If Current had an operation such as: > > > > transaction_control get_txn_control_struct(); > > > > [actual signature may vary.....] > > > > There would be no scope, or lifecycle issues with `control' and no > > forced use of implementation_specific_any or interposition. (I also > > realize there may be some resistance to introducing this type of > > change in an rtf, so its only one of the possible solutions listed > > below.) > > > > > > In summary, I'm asking the rtf to consider: > > > > 1. Whether the Current methods that use control are unecessarily > > forcing implementations to interpose, use implementation_specific_any, > > create local, non-interposed controls or other proprietary solutions. > > > > Some possible solutions: > > > > A. Provide: > > Current::getCoordinator(), > > Current::getTerminator() > > > > so that at least in many cases the ots runtime doesn't always > > have to obtain a control object to provide what it already > > knows. There are no versioning issues with Current since it is > > locality constrained. > > > > (When and if Current::get_control() is called, the ots can > > obtain the control reference at that point. It may still have > > to use interposition to do this, but it can now be avoided some > > of the time.) > > > > B. Provide a struct representation of Control, and corresponding > > operations on Current. > > > > The operations that would need `struct' equivalent are: > > get_control() > > suspend() > > resume() > > > > C. Pass the control explicitly in the propagation_context. (This would > then > > possibly make a remote call to get coordinator and terminator > > references that are already known locally.) > > > > Solution A is a workable solution for an rtf, Solution B addresses the > > issue more completely, and C well, I wouldn't vote for it. > > > > Comments, Opinions? Is Control as an object providing real value or is > > it just a struct in disguise complicating implementations? > > > > > > Cheers, > > > > Ted > > > > -- > > Ted McFadden tmcf@ooc.com.au > > Object Oriented Concepts http://www.ooc.com > > Suite 4 904 Stanley St. +61-7-3891-5744 > > East Brisbane 4169, QLD. Australia > > > > Date: Tue, 10 Oct 2000 11:54:49 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ted McFadden CC: issues@omg.org, ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations References: <20001009134246.B786@ooc.com.au> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: $Sm!!ML7!!~f0e9pXE!! Hello Ted, comments inlined.. Ted McFadden wrote: > > In summary, I'm asking the rtf to consider: > > 1. Whether the Current methods that use control are unecessarily > forcing implementations to interpose, use implementation_specific_any, > create local, non-interposed controls or other proprietary solutions. > > Some possible solutions: > > A. Provide: > Current::getCoordinator(), > Current::getTerminator() > > so that at least in many cases the ots runtime doesn't always > have to obtain a control object to provide what it already > knows. There are no versioning issues with Current since it is > locality constrained. > > (When and if Current::get_control() is called, the ots can > obtain the control reference at that point. It may still have > to use interposition to do this, but it can now be avoided some > of the time.) Avoiding creating the control object, but lazily creating one when current.get_control() is invoked, seems like an optimization which vendor implementations (interposed or non-interposed) could do today transparently. Adding new methods to the current object helps to only limit the need to call on current.get_control(). But why ? Interposed or non-interposed, providing (creating) a control object is not an impossibility and not an overhead. Having a control object serves to encapsulate the control information, and avoids it from spilling over into Currrent (which should _theoretically_ have only thread-transaction association info). As an aside, implementation_specific_data provides ways to do optimizations in homogenous environments. If an ORB detects that it is indeed talking to a different vendor ORB (say through IOR info), then the propagation context should not use implementation_specific_data, but use the standard OTS propagation context info in order to interoperate. > > B. Provide a struct representation of Control, and corresponding > operations on Current. > > The operations that would need `struct' equivalent are: > get_control() > suspend() > resume() This will break legacy applications. > > C. Pass the control explicitly in the propagation_context. (This > would then > possibly make a remote call to get coordinator and terminator > references that are already known locally.) > > Solution A is a workable solution for an rtf, Solution B addresses > the > issue more completely, and C well, I wouldn't vote for it. > > Comments, Opinions? Is Control as an object providing real value or > is > it just a struct in disguise complicating implementations? Having the Control as an object helps to add more behaviour in future (say when designing an extended transaction model based on OTS), as against a simple struct. Regards Ram Date: Tue, 10 Oct 2000 17:09:32 -0230 From: Matthew Newhook To: Ram Jeyaraman Cc: Ted McFadden , issues@omg.org, ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001010170932.A25714@ooc.com> References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <39E365F9.6EB3BC0C@eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: h$%e9Z2d!!>1Pe9B`De9 Hi, On Tue, Oct 10, 2000 at 11:54:49AM -0700, Ram Jeyaraman wrote: > [...] > Avoiding creating the control object, but lazily creating one when current.get_control() is invoked, > seems like an optimization which vendor implementations (interposed or non-interposed) could do > today transparently. How could an OTS do this transparently in one the client side in a pure client application? Firstly there is no server. Secondly, how is the lifecycle of the Control object managed? When is the control destroyed? What happens if the client goes away but the IOR of the Control is saved. > Adding new methods to the current object helps to only limit the need to call on > current.get_control(). But why ? Interposed or non-interposed, providing (creating) a control object > is not an impossibility and not an overhead. It's perhaps not an impossibility (although I do think it's not as trivial as you think, and under some circumstances it is not possible) -- but there absolutely is overhead. Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Tue, 10 Oct 2000 13:33:41 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Ram Jeyaraman , Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001010170932.A25714@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: BDV!!+GT!!0)Z!!W$n!! Hi, Matthew Newhook wrote: > > Hi, > > On Tue, Oct 10, 2000 at 11:54:49AM -0700, Ram Jeyaraman wrote: > > [...] > > Avoiding creating the control object, but lazily creating one when current.get_control() is invoked, > > seems like an optimization which vendor implementations (interposed or non-interposed) could do > > today transparently. > > How could an OTS do this transparently in one the client side in a pure > client application? Firstly there is no server. Secondly, how is the > lifecycle of the Control object managed? When is the control destroyed? > What happens if the client goes away but the IOR of the Control is > saved. i don't quite understand why creating a control object on the client side is impossible, given thet a coordinator and a terminator do exist for every transaction. Most importantly, the control object _is_ thread independent. Any arbitrary thread could use the control information, and complete the transaction. But the same is not true for current object which is thread specific. So, we need to preserve the thread-indepedent semantics of the control object. The control should be destroyed as part of transaction completion. An application which explicitly stores a handle to the Control object and use it later on might re-activate the Control. Now the life of the control object is in the hands of the application :) Since objects being location transparent, it should not matter if the control is local or remote. In the local case, destroying only removes the object from active map, but the client still will be able to use it (i hope that is true in the case of C++ ORBs as well). In the remote case, the object needs to be re-activated. Depending on the QoS offered by the OTS implementation, control objects could be allowed to be re-activated and even the tx state re-read from persistent store. > > > Adding new methods to the current object helps to only limit the need to call on > > current.get_control(). But why ? Interposed or non-interposed, providing (creating) a control object > > is not an impossibility and not an overhead. > > It's perhaps not an impossibility (although I do think it's not as > trivial as you think, and under some circumstances it is not possible) > -- but there absolutely is overhead. True, creating a control object is an overhead, but pales in significance given the # of objects created/activated during the life-time of a request. Regards, Ram Date: Tue, 10 Oct 2000 18:16:48 -0230 From: Matthew Newhook To: Ram Jeyaraman Cc: Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001010181648.A26260@ooc.com> References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001010170932.A25714@ooc.com> <39E37D25.EC6D1625@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <39E37D25.EC6D1625@eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: _^Q!!/X-!![S@e9)cTd9 Hi Ram, On Tue, Oct 10, 2000 at 01:33:41PM -0700, Ram Jeyaraman wrote: > [..]. > i don't quite understand why creating a control object on the client > side is impossible, given thet a coordinator and a terminator do exist > for every transaction. There could be a variety of issues. Firstly, there may be no server. That is there may be no object-adapter, or any sort of server side. Secondly, it wouldn't be clear WHEN to destroy the Control object. Clearly, the control is valid for the lifespan of the transaction. However, the client won't necessarily have any indicatation that the transaction is over (unless it registers a resource -- which is expensive and complex). Also, it's entirely possible for the client to go away (that is terminate) before the transaction is over. However, if some other client is using that Control then it won't understand why the control has disappeared while the transaction is still in progress. > Most importantly, the control object _is_ thread independent. Any arbitrary thread could use the > control information, and complete the transaction. But the same is not true for current object which > is thread specific. So, we need to preserve the thread-indepedent semantics of the control object. > > The control should be destroyed as part of transaction completion. An application which explicitly > stores a handle to the Control object and use it later on might re-activate the Control. Now the > life of the control object is in the hands of the application :) No it's not. How can you arrange for the Control to be destroyed when the transaction is over, besides registering a resource (and expensive proposition)? > Since objects being location transparent, it should not matter if the control is local or remote. In > the local case, destroying only removes the object from active map, but the client still will be > able to use it (i hope that is true in the case of C++ ORBs as well). > In the remote case, the object > needs to be re-activated. Depending on the QoS offered by the OTS implementation, control objects > could be allowed to be re-activated and even the tx state re-read from persistent store. So then you need some sort of servant activator? When do you clear the activation map? When the transaction terminates? How do you know when the transaction terminates? > > > is not an impossibility and not an overhead. > > > > It's perhaps not an impossibility (although I do think it's not as > > trivial as you think, and under some circumstances it is not possible) > > -- but there absolutely is overhead. > > True, creating a control object is an overhead, but pales in significance given the # of objects > created/activated during the life-time of a request. That's simply not true. It's a very difficult problem. > Regards, > Ram Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Tue, 10 Oct 2000 14:40:06 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Ram Jeyaraman , Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001010170932.A25714@ooc.com> <39E37D25.EC6D1625@eng.sun.com> <20001010181648.A26260@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ^T[d9APF!!U\#"!6f)e9 Hi, comments inlined. Matthew Newhook wrote: > > Hi Ram, > > On Tue, Oct 10, 2000 at 01:33:41PM -0700, Ram Jeyaraman wrote: > > [..]. > > i don't quite understand why creating a control object on the client > > side is impossible, given thet a coordinator and a terminator do exist > > for every transaction. > > There could be a variety of issues. Firstly, there may be no server. > That is there may be no object-adapter, or any sort of server side. > Secondly, it wouldn't be clear WHEN to destroy the Control object. > Clearly, the control is valid for the lifespan of the transaction. > However, the client won't necessarily have any indicatation that the > transaction is over (unless it registers a resource -- which is expensive > and complex). Also, it's entirely possible for the client to go away > (that is terminate) before the transaction is over. However, if some > other client is using that Control then it won't understand why the > control has disappeared while the transaction is still in progress. > > > Most importantly, the control object _is_ thread independent. Any arbitrary thread could use the > > control information, and complete the transaction. But the same is not true for current object which > > is thread specific. So, we need to preserve the thread-indepedent semantics of the control object. > > > > The control should be destroyed as part of transaction completion. An application which explicitly > > stores a handle to the Control object and use it later on might re-activate the Control. Now the > > life of the control object is in the hands of the application :) > > No it's not. How can you arrange for the Control to be destroyed when > the transaction is over, besides registering a resource (and expensive > proposition)? i think it is the responsibility of the implementation to bookkeep information on objects created as part of a transaction and clean them up as part of commit / abort call. I do not see any inadequacies in implementing the APIs and the associated behaviour required by the OTS specification. Circumventing the usage of control object, or reducing the control object to a struct is not a good idea; but i certainly agree that an implementation could lazily create control objects _on_demand_ as an optimization. > > > Since objects being location transparent, it should not matter if the control is local or remote. In > > the local case, destroying only removes the object from active map, but the client still will be > > able to use it (i hope that is true in the case of C++ ORBs as well). > > In the remote case, the object > > needs to be re-activated. Depending on the QoS offered by the OTS implementation, control objects > > could be allowed to be re-activated and even the tx state re-read from persistent store. > > So then you need some sort of servant activator? When do you clear the > activation map? When the transaction terminates? How do you know when > the transaction terminates? terminator.commit/rollback call should destroy the associated objects. Destroying only removes it from the activation map, but if an application explicitly hangs on to a reference, the object is still available (this is not true in the case of remote objects, unless they have an appropriate policy to re-activate them, which could be done based on QoS). > > > > > is not an impossibility and not an overhead. > > > > > > It's perhaps not an impossibility (although I do think it's not as > > > trivial as you think, and under some circumstances it is not possible) > > > -- but there absolutely is overhead. > > > > True, creating a control object is an overhead, but pales in significance given the # of objects > > created/activated during the life-time of a request. > > That's simply not true. It's a very difficult problem. > > > Regards, > > Ram > Date: Tue, 10 Oct 2000 20:03:37 -0230 From: Matthew Newhook To: Ram Jeyaraman Cc: Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001010200337.A26985@ooc.com> References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001010170932.A25714@ooc.com> <39E37D25.EC6D1625@eng.sun.com> <20001010181648.A26260@ooc.com> <39E38CB6.B860E06F@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <39E38CB6.B860E06F@eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: H:S!!cC?!!k"Fe9FY)e9 Hi, On Tue, Oct 10, 2000 at 02:40:06PM -0700, Ram Jeyaraman wrote: > > [...] > > No it's not. How can you arrange for the Control to be destroyed when > > the transaction is over, besides registering a resource (and expensive > > proposition)? > > i think it is the responsibility of the implementation to bookkeep information on objects created as > part of a transaction and clean them up as part of commit / abort call. I do not see any > inadequacies in implementing the APIs and the associated behaviour required by the OTS > specification. How? Please explain how this can occur when the transaction can be committed in another process? > Circumventing the usage of control object, or reducing the control object to a struct is not a good > idea; but i certainly agree that an implementation could lazily create control objects _on_demand_ > as an optimization. I don't see how this is possible. Please explain. > > [...] > > So then you need some sort of servant activator? When do you clear > > the > > activation map? When the transaction terminates? How do you know > > when > > the transaction terminates? > > terminator.commit/rollback call should destroy the associated > > objects. No -- this is not possible. The commit/rollback could occur in some other process in which case the process that creates this "interposed" control object will never find out about the commit/rollback unless a resource is registered (which is complex and tedious and inefficient). And ALL of these arguments assume that the client is *capable* of creating a control object. If the client doesn't have any sort of server-side capability then it not possible to create a control object. Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Sender: jbiggar@corvette.floorboard.com Message-ID: <39E3A115.274F2D7B@floorboard.com> Date: Tue, 10 Oct 2000 16:07:01 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Ram Jeyaraman , Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001010170932.A25714@ooc.com> <39E37D25.EC6D1625@eng.sun.com> <20001010181648.A26260@ooc.com> <39E38CB6.B860E06F@eng.sun.com> <20001010200337.A26985@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 9'Le9~jSd9@1/!!HTgd9 Matthew Newhook wrote: > And ALL of these arguments assume that the client is *capable* of creating > a control object. If the client doesn't have any sort of server-side > capability then it not possible to create a control object. Another solution to the problem would be to change the definition of the control interface to be a local interface. Since the spec already states that an implementation is free to restrict control to only working locally, this isn't a change in semantics, and significantly eases the lifecycle problem. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 10 Oct 2000 16:53:35 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Ram Jeyaraman , Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001010170932.A25714@ooc.com> <39E37D25.EC6D1625@eng.sun.com> <20001010181648.A26260@ooc.com> <39E38CB6.B860E06F@eng.sun.com> <20001010200337.A26985@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 2C0e9cC+!!Mg9e9kiJe9 Hi Mathew, Matthew Newhook wrote: > > Hi, > > On Tue, Oct 10, 2000 at 02:40:06PM -0700, Ram Jeyaraman wrote: > > > [...] > > > No it's not. How can you arrange for the Control to be destroyed when > > > the transaction is over, besides registering a resource (and expensive > > > proposition)? > > > > i think it is the responsibility of the implementation to bookkeep information on objects created as > > part of a transaction and clean them up as part of commit / abort call. I do not see any > > inadequacies in implementing the APIs and the associated behaviour required by the OTS > > specification. > > How? Please explain how this can occur when the transaction can be > committed in another process? > > > Circumventing the usage of control object, or reducing the control object to a struct is not a good > > idea; but i certainly agree that an implementation could lazily create control objects _on_demand_ > > as an optimization. > > I don't see how this is possible. Please explain. > > > > [...] > > > So then you need some sort of servant activator? When do you clear the > > > activation map? When the transaction terminates? How do you know when > > > the transaction terminates? > > > > terminator.commit/rollback call should destroy the associated objects. > > No -- this is not possible. The commit/rollback could occur in some > other process in which case the process that creates this "interposed" > control object will never find out about the commit/rollback unless a > resource is registered (which is complex and tedious and inefficient). Yes, without having a resource registered for the subordinate coordinator it is impossible to know of completion. But it is possible for vendor implementations to do optimizations using the implementation_specific_data or by better knowledge of the data distribution (for example if one knows the same RM is used). But vendor implementations interested in interoperability need to avoid implementation_specific_data and use the standard protocol (register a resource on behalf of the subordinate coordinator to get tx completion notification), _atleast_ while interoperating with heterogenous implementations. > > And ALL of these arguments assume that the client is *capable* of > creating > a control object. If the client doesn't have any sort of server-side > capability then it not possible to create a control object. If a client is able to access an OTS service and start a transaction, why is it not possible for the OTS to provide a control object ? Anyway, my main concern is about the removal of the control interface and is not about being able to reclaim control objects or about not being able to create them. The control interface provides a thread-independent mechanism to control tx boundaries, and it cannot be substituted by adding accessor methods to the Current interface whose behaviour is thread specific. Regards, Ram Date: Tue, 10 Oct 2000 16:57:46 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: Matthew Newhook , Ram Jeyaraman , Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001010170932.A25714@ooc.com> <39E37D25.EC6D1625@eng.sun.com> <20001010181648.A26260@ooc.com> <39E38CB6.B860E06F@eng.sun.com> <20001010200337.A26985@ooc.com> <39E3A115.274F2D7B@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 0Md!!~?4!!iF > Matthew Newhook wrote: > > And ALL of these arguments assume that the client is *capable* of creating > > a control object. If the client doesn't have any sort of server-side > > capability then it not possible to create a control object. > > Another solution to the problem would be to change the definition of the > control interface to be a local interface. Since the spec already > states that an implementation is free to restrict control to only > working locally, this isn't a change in semantics, and significantly > eases the lifecycle problem. But vendor implementations could do such optimizations like locally constraining the control object, or even activating local objects only when their IOR is exported to an external process (on-demand). i think the spec should describe the required behaviour and the architecture, and leave it upto the vendor implementations to do such optimziations. Regards Ram Date: Tue, 10 Oct 2000 22:36:50 -0230 From: Matthew Newhook To: Ram Jeyaraman Cc: Jonathan Biggar , Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001010223650.A27824@ooc.com> References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001010170932.A25714@ooc.com> <39E37D25.EC6D1625@eng.sun.com> <20001010181648.A26260@ooc.com> <39E38CB6.B860E06F@eng.sun.com> <20001010200337.A26985@ooc.com> <39E3A115.274F2D7B@floorboard.com> <39E3ACFA.A25D12FF@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <39E3ACFA.A25D12FF@eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: 30[!!2Gl!!H1 Hi Jon, > > Jonathan Biggar wrote: > > > > Matthew Newhook wrote: > > > And ALL of these arguments assume that the client is *capable* of creating > > > a control object. If the client doesn't have any sort of server-side > > > capability then it not possible to create a control object. > > > > Another solution to the problem would be to change the definition of the > > control interface to be a local interface. Since the spec already > > states that an implementation is free to restrict control to only > > working locally, this isn't a change in semantics, and significantly > > eases the lifecycle problem. > > But vendor implementations could do such optimizations like locally constraining the control object, > or even activating local objects only when their IOR is exported to an external process (on-demand). > > i think the spec should describe the required behaviour and the architecture, and leave it upto the > vendor implementations to do such optimziations. No, unfortunately neither is possible. If you use explicit transaction propagation it must be possible to pass the Control object across the wire. > Regards > Ram Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Tue, 10 Oct 2000 22:40:21 -0230 From: Matthew Newhook To: Ram Jeyaraman Cc: Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001010224021.B27824@ooc.com> References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001010170932.A25714@ooc.com> <39E37D25.EC6D1625@eng.sun.com> <20001010181648.A26260@ooc.com> <39E38CB6.B860E06F@eng.sun.com> <20001010200337.A26985@ooc.com> <39E3ABFF.61A9960@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <39E3ABFF.61A9960@eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: _IQd9**'!!a4J!!@$3!! Hi, On Tue, Oct 10, 2000 at 04:53:35PM -0700, Ram Jeyaraman wrote: > > [...] > > No -- this is not possible. The commit/rollback could occur in some > > other process in which case the process that creates this "interposed" > > control object will never find out about the commit/rollback unless a > > resource is registered (which is complex and tedious and inefficient). > > Yes, without having a resource registered for the subordinate coordinator it is impossible to know > of completion. But it is possible for vendor implementations to do optimizations using the > implementation_specific_data or by better knowledge of the data distribution (for example if one > knows the same RM is used). Sure... but interoperability is then out the window. It's not a question of optimization -- it's a question of simple operation. > But vendor implementations interested in interoperability need to avoid implementation_specific_data > and use the standard protocol (register a resource on behalf of the subordinate coordinator to get > tx completion notification), _atleast_ while interoperating with heterogenous implementations. Yes... that is an option. But it's not a nice option. Registering a resource is not a cheap thing to do. > > And ALL of these arguments assume that the client is *capable* of creating > > a control object. If the client doesn't have any sort of server-side > > capability then it not possible to create a control object. > > If a client is able to access an OTS service and start a transaction, why is it not possible for the > OTS to provide a control object ? Because creation of a control object implies the presence of an object-adapter. Starting a transaction and accessing an OTS service does not -- that is purely a client side activity. > Anyway, my main concern is about the removal of the control interface and is not about being able to > reclaim control objects or about not being able to create them. That's fine -- except our concern is the ability to write an OTS implementation that can interoperate with other OTS implementations. The fact that the control object is not propagated we believe hinders this. > The control interface provides a thread-independent mechanism to control tx boundaries, and it > cannot be substituted by adding accessor methods to the Current interface whose behaviour is thread > specific. I agree with that. However, two of Ted's proposals has nothing to do with that. What he proposed was to either change Control to a struct, or to pass the Control object with the Propagation context. Unfortunately, neither is backwards compatible :( > Regards, > Ram Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Sender: jon@corvette.floorboard.com Message-ID: <39E3C13C.660DABBA@floorboard.com> Date: Tue, 10 Oct 2000 18:24:12 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Ram Jeyaraman , Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001010170932.A25714@ooc.com> <39E37D25.EC6D1625@eng.sun.com> <20001010181648.A26260@ooc.com> <39E38CB6.B860E06F@eng.sun.com> <20001010200337.A26985@ooc.com> <39E3A115.274F2D7B@floorboard.com> <39E3ACFA.A25D12FF@eng.sun.com> <20001010223650.A27824@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: P)8e9KC#!!Sn#"!n > > Another solution to the problem would be to change the definition of the > > > control interface to be a local interface. Since the spec already > > > states that an implementation is free to restrict control to only > > > working locally, this isn't a change in semantics, and significantly > > > eases the lifecycle problem. > > > > But vendor implementations could do such optimizations like locally constraining the control object, > > or even activating local objects only when their IOR is exported to an external process (on-demand). > > > > i think the spec should describe the required behaviour and the architecture, and leave it upto the > > vendor implementations to do such optimziations. > > No, unfortunately neither is possible. If you use explicit transaction > propagation it must be possible to pass the Control object across > the wire. Doesn't that mean the spec is inconsistent? The text for Current::get_control() says that the Control object only has to be valid for the current thread, yet the explicit propagation rules rely on passing the Control object to another process... Sounds like I need to raise an issue... -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 10 Oct 2000 23:14:44 -0230 From: Matthew Newhook To: Jonathan Biggar Cc: Ram Jeyaraman , Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001010231444.B28184@ooc.com> References: <39E365F9.6EB3BC0C@eng.sun.com> <20001010170932.A25714@ooc.com> <39E37D25.EC6D1625@eng.sun.com> <20001010181648.A26260@ooc.com> <39E38CB6.B860E06F@eng.sun.com> <20001010200337.A26985@ooc.com> <39E3A115.274F2D7B@floorboard.com> <39E3ACFA.A25D12FF@eng.sun.com> <20001010223650.A27824@ooc.com> <39E3C13C.660DABBA@floorboard.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <39E3C13C.660DABBA@floorboard.com> Content-Type: text/plain; charset=us-ascii X-UIDL: cL"e92nHe95I;e92KBe9 Hi, On Tue, Oct 10, 2000 at 06:24:12PM -0700, Jonathan Biggar wrote: > > [...] > > No, unfortunately neither is possible. If you use explicit transaction > > propagation it must be possible to pass the Control object across > > the wire. > > Doesn't that mean the spec is inconsistent? The text for > Current::get_control() says that the Control object only has to be valid > yet the explicit propagation rules rely on > passing the Control object to another process... > > Sounds like I need to raise an issue... Yes, it is somewhat inconsistent. Except if you are using explicit propagation you'd most likely not have a Current object -- you'd generally use the TransactionFactory to create the Control. > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 11 Oct 2000 11:49:44 +1000 From: Ted McFadden To: Ram Jeyaraman Cc: issues@omg.org, ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001011114943.C672@ooc.com.au> Mail-Followup-To: Ram Jeyaraman , issues@omg.org, ots-rtf@omg.org References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i In-Reply-To: <39E365F9.6EB3BC0C@eng.sun.com>; from Ram.Jeyaraman@eng.sun.com on Tue, Oct 10, 2000 at 11:54:49AM -0700 Content-Type: text/plain; charset=us-ascii X-UIDL: %'Yd9!W5!!A_/!!>]i!! On Tue, Oct 10, 2000 at 11:54:49AM -0700, Ram Jeyaraman wrote: Hi Ram, A lot of discussion has already taken place, so I'll try not to be (too) redundant but I do have a few comments: > Hello Ted, > > comments inlined.. > > Ted McFadden wrote: > > > > In summary, I'm asking the rtf to consider: > > > > 1. Whether the Current methods that use control are unecessarily > > forcing implementations to interpose, use > implementation_specific_any, > > create local, non-interposed controls or other proprietary > solutions. > > > > Some possible solutions: > > > > A. Provide: > > Current::getCoordinator(), > > Current::getTerminator() > > > > so that at least in many cases the ots runtime doesn't > always > > have to obtain a control object to provide what it already > > knows. There are no versioning issues with Current since it > is > > locality constrained. > > > > (When and if Current::get_control() is called, the ots can > > obtain the control reference at that point. It may still > have > > to use interposition to do this, but it can now be avoided > some > > of the time.) > > Avoiding creating the control object, but lazily creating one when > current.get_control() is invoked, > seems like an optimization which vendor implementations (interposed > or non-interposed) could do > today transparently. The immediate problem is not the lazy evaluation of get_control(). As in the example I gave, you can't access the coordinator without going through a control, even though the OTS runtime already has received the control in the propagation_context with the request. So lazy, eval or not, currently a control *always* has to be obtained somehow. I might not complain if that control were in the propagation context but its not, but even if it was I end up with an RPC call to get an object reference that is already locally known. The OTS spec exhibits a bit of a split personality here. Either control should represent the transaction or Coordinator/Terminator do. The problem arises because OTS is not quite self consistent in its implicit propagation model. > > Adding new methods to the current object helps to only limit the > need to call on > current.get_control(). But why ? Interposed or non-interposed, > providing (creating) a control object > is not an impossibility and not an overhead. > Forcing every program using OTS to either use interposition or to manufacture control objects is an overhead. But if that's what's required the spec should say so. > Having a control object serves to encapsulate the control information, and avoids it from spilling > over into Currrent (which should _theoretically_ have only thread-transaction association info). > If the control object is the proper interface for encapsulating the transaction info, then why isn't it passed around in the propagation context instead of the coordinator / terminator pair? > As an aside, implementation_specific_data provides ways to do optimizations in homogenous > environments. If an ORB detects that it is indeed talking to a different vendor ORB (say through IOR > info), then the propagation context should not use implementation_specific_data, but use the > standard OTS propagation context info in order to interoperate. > If an implementation has to reply on implementation_specific_data it cannot be interoperable with other vendor impls in a general sense. For example, the hack of putting the control reference in the implementation_specific_any works if that control is received with a request. If another vendor OTS doesn't send it, what is my OTS supposed to do? It either has to manufacture control references or force use of interposition. Which I have to say is a pretty poor interoperability scenario. I really don't want to see us have to do an Interoperable OTS spec at some point. ;) > > > > B. Provide a struct representation of Control, and > > corresponding > > operations on Current. > > > > The operations that would need `struct' equivalent are: > > get_control() > > suspend() > > resume() > > This will break legacy applications. > A clarification, I didn't say remove the old operations, just add the new ones. Then we can say to customers, if you want to use the `control' versions of the current methods, then you either run in a homogeneous environment or you use interposition. If you don't want that overhead and would like interoperability with other vendors, you use the struct versions. In which case our implementation doesn't have to touch implementation_specific_any. If solution A was implemented, at least it could be said no interposition overhead or local controls would have to be manufactured if you do not suspend or resume a transaction. > > > > C. Pass the control explicitly in the > > propagation_context. (This would then > > possibly make a remote call to get coordinator and > > terminator > > references that are already known locally.) > > > > Solution A is a workable solution for an rtf, Solution B addresses > > the > > issue more completely, and C well, I wouldn't vote for it. > > > > Comments, Opinions? Is Control as an object providing real value > > or is > > it just a struct in disguise complicating implementations? > > Having the Control as an object helps to add more behaviour in > > future (say when designing an > extended transaction model based on OTS), as against a simple > > struct. > Again, if Control is really going to represent the transaction, it must be used consistently in the spec. If a client has to create one locally, what additional functionality could it really have? The manufactured control would still have to redirect everything through the coordinator/terminator pair the OTS received in the propagation context. Cheers, Ted > Regards > Ram -- Ted McFadden tmcf@ooc.com.au Object Oriented Concepts http://www.ooc.com Suite 4 904 Stanley St. +61-7-3891-5744 East Brisbane 4169, QLD. Australia Sender: jon@corvette.floorboard.com Message-ID: <39E3C755.337D2195@floorboard.com> Date: Tue, 10 Oct 2000 18:50:13 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Ram Jeyaraman , Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations References: <39E365F9.6EB3BC0C@eng.sun.com> <20001010170932.A25714@ooc.com> <39E37D25.EC6D1625@eng.sun.com> <20001010181648.A26260@ooc.com> <39E38CB6.B860E06F@eng.sun.com> <20001010200337.A26985@ooc.com> <39E3A115.274F2D7B@floorboard.com> <39E3ACFA.A25D12FF@eng.sun.com> <20001010223650.A27824@ooc.com> <39E3C13C.660DABBA@floorboard.com> <20001010231444.B28184@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: L,3e9DA?e9f4ld9FC > Doesn't that mean the spec is inconsistent? The text for > > Current::get_control() says that the Control object only has to be valid > > yet the explicit propagation rules rely on > > passing the Control object to another process... > > > > Sounds like I need to raise an issue... > > Yes, it is somewhat inconsistent. Except if you are using explicit > propagation you'd most likely not have a Current object -- you'd generally > use the TransactionFactory to create the Control. So are you suggesting that the Control returned from Current can have different restrictions than the one returned from TransactionFactory? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 11 Oct 2000 11:59:23 +1000 From: Ted McFadden To: Jonathan Biggar Cc: Matthew Newhook , Ram Jeyaraman , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001011115923.D672@ooc.com.au> Mail-Followup-To: Jonathan Biggar , Matthew Newhook , Ram Jeyaraman , ots-rtf@omg.org References: <39E365F9.6EB3BC0C@eng.sun.com> <20001010170932.A25714@ooc.com> <39E37D25.EC6D1625@eng.sun.com> <20001010181648.A26260@ooc.com> <39E38CB6.B860E06F@eng.sun.com> <20001010200337.A26985@ooc.com> <39E3A115.274F2D7B@floorboard.com> <39E3ACFA.A25D12FF@eng.sun.com> <20001010223650.A27824@ooc.com> <39E3C13C.660DABBA@floorboard.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i In-Reply-To: <39E3C13C.660DABBA@floorboard.com>; from jon@floorboard.com on Tue, Oct 10, 2000 at 06:24:12PM -0700 Content-Type: text/plain; charset=us-ascii X-UIDL: )$A!!6/L!!IPh!!g'Wd9 On Tue, Oct 10, 2000 at 06:24:12PM -0700, Jonathan Biggar wrote: > Matthew Newhook wrote: > > > > Another solution to the problem would be to change the definition of the > > > > control interface to be a local interface. Since the spec already > > > > states that an implementation is free to restrict control to only > > > > working locally, this isn't a change in semantics, and significantly > > > > eases the lifecycle problem. > > > > > > But vendor implementations could do such optimizations like locally constraining the control object, > > > or even activating local objects only when their IOR is exported to an external process (on-demand). > > > > > > i think the spec should describe the required behaviour and the architecture, and leave it upto the > > > vendor implementations to do such optimziations. > > > > No, unfortunately neither is possible. If you use explicit transaction > > propagation it must be possible to pass the Control object across > > the wire. > > Doesn't that mean the spec is inconsistent? The text for > Current::get_control() says that the Control object only has to be valid > for the current thread, yet the explicit propagation rules rely on > passing the Control object to another process... > > Sounds like I need to raise an issue... > Hi, Related to that issue, in section 10.3.3, pg 10-23, for the description of Control,the text for get_coordinator(), and get_terminator() all say: An implementation of the Transaction Service may restrict the ability for the [Control | Terminator | Coordinator] to be transmitted to or used in other execution environments; at a minimum, it can used within a single thread. Shouldn't the valid scope of the Control should match that of the Coordinator / Terminator it represents and not be completely independent? Cheers, Ted > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- Ted McFadden tmcf@ooc.com.au Object Oriented Concepts http://www.ooc.com Suite 4 904 Stanley St. +61-7-3891-5744 East Brisbane 4169, QLD. Australia Date: Thu, 12 Oct 2000 14:50:46 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ted McFadden CC: ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001011114943.C672@ooc.com.au> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: (m?!!eS4!!C&cd9oAT!! Hello Ted, comments inlined.. Ted McFadden wrote: > > The OTS spec exhibits a bit of a split personality here. Either control should represent > the transaction or Coordinator/Terminator do. The problem arises because OTS is not > quite self consistent in its implicit propagation model. > > > > > Adding new methods to the current object helps to only limit the need to call on > > current.get_control(). But why ? Interposed or non-interposed, providing (creating) a control object > > is not an impossibility and not an overhead. > > > > Forcing every program using OTS to either use interposition or to > manufacture control objects is an overhead. But if that's what's required > the spec should say so. > i agree. > > Having a control object serves to encapsulate the control information, and avoids it from spilling > > over into Currrent (which should _theoretically_ have only thread-transaction association info). > > > > If the control object is the proper interface for encapsulating the > transaction info, then why isn't it passed around in the propagation > context instead of the coordinator / terminator pair? is it not possible to construct a control object locally using the coordinator / terminator pair instead of using an explicit reference ? you might argue that it is more expensive.. Regards Ram Date: Thu, 12 Oct 2000 19:44:08 -0230 From: Matthew Newhook To: Ram Jeyaraman Cc: Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001012194408.A24134@ooc.com> References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001011114943.C672@ooc.com.au> <39E63236.DAA2B9C@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <39E63236.DAA2B9C@eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: ~Tfd9L'^d9KpR!!jaQd9 Hi, On Thu, Oct 12, 2000 at 02:50:46PM -0700, Ram Jeyaraman wrote: >[...] > > > Having a control object serves to encapsulate the control information, and avoids it from spilling > > > over into Currrent (which should _theoretically_ have only thread-transaction association info). > > > > > > > If the control object is the proper interface for encapsulating the > > transaction info, then why isn't it passed around in the propagation > > context instead of the coordinator / terminator pair? > > is it not possible to construct a control object locally using the coordinator / terminator pair > instead of using an explicit reference ? you might argue that it is more expensive.. No, for all the reasons I said before it may not be possible. To recap: - There may be no server side (that is no object adapter support for the local ORB). - The user may not have configured interposition. - If the user has not enabled interposition then it there are a whole raft of problems (that essentially boil down to an implementation of interposition). The only reasonable way to construct a control object is via interposition -- and that may not always be possible. Even if it is possible, it is very expensive. > Regards > Ram Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 12 Oct 2000 16:32:34 -0700 From: Blake Biesecker To: Matthew Newhook Cc: Ram Jeyaraman , Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001012163234.B526@gemstone.com> References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001011114943.C672@ooc.com.au> <39E63236.DAA2B9C@eng.sun.com> <20001012194408.A24134@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <20001012194408.A24134@ooc.com>; from matthew@ooc.com on Thu, Oct 12, 2000 at 07:44:08PM -0230 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: 0B'!!Af#!!PI Hi, > > On Thu, Oct 12, 2000 at 02:50:46PM -0700, Ram Jeyaraman wrote: > >[...] > > > > Having a control object serves to encapsulate the control information, and avoids it from spilling > > > > over into Currrent (which should _theoretically_ have only thread-transaction association info). > > > > > > > > > > If the control object is the proper interface for encapsulating the > > > transaction info, then why isn't it passed around in the propagation > > > context instead of the coordinator / terminator pair? > > > > is it not possible to construct a control object locally using the coordinator / terminator pair > > instead of using an explicit reference ? you might argue that it is more expensive.. > > No, for all the reasons I said before it may not be possible. To recap: > - There may be no server side (that is no object adapter support for the > local ORB). Matthew, I understand Ram's side of this conversation (and agree with what he has said so far) but I'm struggling to get a handle on your point above. Could you go into more detail about the scenario you are describing above and when it would occur? Blake > - The user may not have configured interposition. > - If the user has not enabled interposition then it there are a > - whole > raft of problems (that essentially boil down to an implementation of > interposition). > > The only reasonable way to construct a control object is via > interposition -- and that may not always be possible. Even if it is > possible, it is very expensive. > > > Regards > > Ram > > Regards, Matthew > -- > Matthew Newhook E-Mail: > - mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 12 Oct 2000 22:46:39 -0230 From: Matthew Newhook To: Blake Biesecker Cc: Ram Jeyaraman , Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001012224639.A25406@ooc.com> References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001011114943.C672@ooc.com.au> <39E63236.DAA2B9C@eng.sun.com> <20001012194408.A24134@ooc.com> <20001012163234.B526@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <20001012163234.B526@gemstone.com> Content-Type: text/plain; charset=us-ascii X-UIDL: C[L!!PcP!!Fe$e95f!e9 Hi, On Thu, Oct 12, 2000 at 04:32:34PM -0700, Blake Biesecker wrote: > Matthew, > > I understand Ram's side of this conversation (and agree with what he > has said so far) but I'm struggling to get a handle on your point above. > Could you go into more detail about the scenario you are describing > above and when it would occur? One possible scenario could be when the user hasn't compiled the server side library into the executable? Besides why shouldl interposition be _required_ to write an interoperable implementation of the OTS? > Blake Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 12 Oct 2000 19:05:11 -0700 From: Blake Biesecker To: Matthew Newhook Cc: Ram Jeyaraman , Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001012190511.F526@gemstone.com> References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001011114943.C672@ooc.com.au> <39E63236.DAA2B9C@eng.sun.com> <20001012194408.A24134@ooc.com> <20001012163234.B526@gemstone.com> <20001012224639.A25406@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <20001012224639.A25406@ooc.com>; from matthew@ooc.com on Thu, Oct 12, 2000 at 10:46:39PM -0230 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: ]Ycd9ONX!!=Xnd9B`#!! On Thu, Oct 12, 2000 at 10:46:39PM -0230, Matthew Newhook wrote: > Hi, > > On Thu, Oct 12, 2000 at 04:32:34PM -0700, Blake Biesecker wrote: > > Matthew, > > > > I understand Ram's side of this conversation (and agree with what he > > has said so far) but I'm struggling to get a handle on your point above. > > Could you go into more detail about the scenario you are describing > > above and when it would occur? > > One possible scenario could be when the user hasn't compiled the server > side library into the executable? > I must be missing something. Interposition requires that a new Control be created that refers to a new Coordinator which needs to register itself with the Coordinator reference passed in by the PropagationContext. I'm not seeing how this requires anything less than creating a new Control and initialize it with the Coordinator and Terminator references in the PropagationContext. > > Besides why shouldl interposition be _required_ to write an > interoperable > implementation of the OTS? > Because I don't see that it is needed at the moment. And it seems to me that interposition can be less efficient if you are only expecting one Resource to register locally. Blake > > Blake > > Regards, Matthew > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Fri, 13 Oct 2000 12:07:56 +1000 From: Ted McFadden To: Ram Jeyaraman Cc: ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001013120756.B16281@ooc.com.au> Mail-Followup-To: Ram Jeyaraman , ots-rtf@omg.org References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001011114943.C672@ooc.com.au> <39E63236.DAA2B9C@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i In-Reply-To: <39E63236.DAA2B9C@eng.sun.com>; from Ram.Jeyaraman@eng.sun.com on Thu, Oct 12, 2000 at 02:50:46PM -0700 Content-Type: text/plain; charset=us-ascii X-UIDL: 0~B!!APQd9_##e9*$>!! On Thu, Oct 12, 2000 at 02:50:46PM -0700, Ram Jeyaraman wrote: Hi Ram, > Hello Ted, > > comments inlined.. > > Ted McFadden wrote: > > [ some snipping] > > > > Having a control object serves to encapsulate the control > information, and avoids it from spilling > > > over into Currrent (which should _theoretically_ have only > thread-transaction association info). > > > > > > > If the control object is the proper interface for encapsulating > the > > transaction info, then why isn't it passed around in the > propagation > > context instead of the coordinator / terminator pair? > > is it not possible to construct a control object locally using the > coordinator / terminator pair > instead of using an explicit reference ? you might argue that it is > more expensive.. > Yes it is possible to create a control locally, if you want to make the process a `control' server. It is just such a waste to have to do it to gain access to an object that is already known locally. The only servers involved in a transaction that should produce objects that have some sort of transaction related life cycle are the TransactionFactories and the Controls, Coordinator, Terminators, they create / recreate and the Resources themselves. I do not want to see clients that need access to a coordinator start producing controls that may or may not have the same lifecycle as the transaction. Nor am I too keen on forcing interposition. Trying to keep a summary on the issue: Either: 1. The implicit programming model needs to reduce or eliminate dependency on the control object or provide some portable means of obtaining it. or 2. The spec must state that to be interoperable, every OTS client, in itself must either use interposition or produce local control objects with the same lifecycle as the control produces by the originating TransactionFactory. If interoperability is not an issue, (WHICH IT SHOULD BE) an implementation can use implementation_specific_any or another proprietary means of obtaining the control. Number 2 is along the lines of what is currently implied by the spec. I think its asking a lot of clients. Cheers, Ted -- Ted McFadden tmcf@ooc.com.au Object Oriented Concepts http://www.ooc.com Suite 4 904 Stanley St. +61-7-3891-5744 East Brisbane 4169, QLD. Australia Date: Fri, 13 Oct 2000 10:10:05 -0230 From: Matthew Newhook To: Blake Biesecker Cc: Ram Jeyaraman , Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001013101005.A31637@ooc.com> References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001011114943.C672@ooc.com.au> <39E63236.DAA2B9C@eng.sun.com> <20001012194408.A24134@ooc.com> <20001012163234.B526@gemstone.com> <20001012224639.A25406@ooc.com> <20001012190511.F526@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <20001012190511.F526@gemstone.com> Content-Type: text/plain; charset=us-ascii X-UIDL: YS;!!!M:!!$MQd9+LMe9 Hi, On Thu, Oct 12, 2000 at 07:05:11PM -0700, Blake Biesecker wrote: > > [...] > > One possible scenario could be when the user hasn't compiled the server > > side library into the executable? > > I must be missing something. Interposition requires that a new Control > be created that refers to a new Coordinator which needs to register > itself with the Coordinator reference passed in by the PropagationContext. > I'm not seeing how this requires anything less than creating a new Control > and initialize it with the Coordinator and Terminator references in the > PropagationContext. Where is the Control created? If there is NO interposition it must be locally. Since Control is a full CORBA object the creation of a Control and associated reference MUST require an object-adapter and hence a server side. > > Besides why shouldl interposition be _required_ to write an interoperable > > implementation of the OTS? > > > > Because I don't see that it is needed at the moment. That's simply not true. Interposition (for all intents and purposes) is required because there is no other way to create a new Control object. > And it seems to me that > interposition can be less efficient if you are only expecting one > Resource > to register locally. Clients never register resources -- they are pure clients and only call methods on servers. They may, however, want to suspect and resume the transaction which requires the Control object. > Blake Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: "Eric Newcomer" To: "Ted McFadden" , "Ram Jeyaraman" Cc: , Subject: RE: Issue with CosTransactions::Control and implicit propagation implementations Date: Fri, 13 Oct 2000 11:57:33 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <20001011114943.C672@ooc.com.au> Content-Type: text/plain; charset="us-ascii" X-UIDL: b~H!!j9,!!oF%!!?P8e9 Another possibility to consider is defining a profile of requirements expressly for the purpose of achieving interoperability. This isn't really defined today and gives rise to some of the issues discussed on this thread. Peter Furniss a while back sketched this out, I'll try to find the email. Basically he proposed requiring interposition for interoperability. That would leave existing implementations of the spec undisturbed and provide a framework for ensuring interoperability by defining a subset or specific interpretation of the spec. Eric -----Original Message----- From: Ted McFadden [mailto:tmcf@ooc.com.au] Sent: Tuesday, October 10, 2000 9:50 PM To: Ram Jeyaraman Cc: issues@omg.org; ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations On Tue, Oct 10, 2000 at 11:54:49AM -0700, Ram Jeyaraman wrote: Hi Ram, A lot of discussion has already taken place, so I'll try not to be (too) redundant but I do have a few comments: > Hello Ted, > > comments inlined.. > > Ted McFadden wrote: > > > > In summary, I'm asking the rtf to consider: > > > > 1. Whether the Current methods that use control are unecessarily > > forcing implementations to interpose, use >implementation_specific_any, > > create local, non-interposed controls or other proprietary >solutions. > > > > Some possible solutions: > > > > A. Provide: > > Current::getCoordinator(), > > Current::getTerminator() > > > > so that at least in many cases the ots runtime doesn't >always > > have to obtain a control object to provide what it already > > knows. There are no versioning issues with Current since it >is > > locality constrained. > > > > (When and if Current::get_control() is called, the ots can > > obtain the control reference at that point. It may still >have > > to use interposition to do this, but it can now be avoided >some > > of the time.) > > Avoiding creating the control object, but lazily creating one when current.get_control() is invoked, > seems like an optimization which vendor implementations (interposed >or non-interposed) could do > today transparently. The immediate problem is not the lazy evaluation of get_control(). As in the example I gave, you can't access the coordinator without going through a control, even though the OTS runtime already has received the control in the propagation_context with the request. So lazy, eval or not, currently a control *always* has to be obtained somehow. I might not complain if that control were in the propagation context but its not, but even if it was I end up with an RPC call to get an object reference that is already locally known. The OTS spec exhibits a bit of a split personality here. Either control should represent the transaction or Coordinator/Terminator do. The problem arises because OTS is not quite self consistent in its implicit propagation model. > > Adding new methods to the current object helps to only limit the >need to call on > current.get_control(). But why ? Interposed or non-interposed, >providing (creating) a control object > is not an impossibility and not an overhead. > Forcing every program using OTS to either use interposition or to manufacture control objects is an overhead. But if that's what's required the spec should say so. > Having a control object serves to encapsulate the control information, and avoids it from spilling > over into Currrent (which should _theoretically_ have only thread-transaction association info). > If the control object is the proper interface for encapsulating the transaction info, then why isn't it passed around in the propagation context instead of the coordinator / terminator pair? > As an aside, implementation_specific_data provides ways to do optimizations in homogenous > environments. If an ORB detects that it is indeed talking to a different vendor ORB (say through IOR > info), then the propagation context should not use implementation_specific_data, but use the > standard OTS propagation context info in order to interoperate. > If an implementation has to reply on implementation_specific_data it cannot be interoperable with other vendor impls in a general sense. For example, the hack of putting the control reference in the implementation_specific_any works if that control is received with a request. If another vendor OTS doesn't send it, what is my OTS supposed to do? It either has to manufacture control references or force use of interposition. Which I have to say is a pretty poor interoperability scenario. I really don't want to see us have to do an Interoperable OTS spec at some point. ;) > > > > B. Provide a struct representation of Control, and > >corresponding > > operations on Current. > > > > The operations that would need `struct' equivalent are: > > get_control() > > suspend() > > resume() > > This will break legacy applications. > A clarification, I didn't say remove the old operations, just add the new ones. Then we can say to customers, if you want to use the `control' versions of the current methods, then you either run in a homogeneous environment or you use interposition. If you don't want that overhead and would like interoperability with other vendors, you use the struct versions. In which case our implementation doesn't have to touch implementation_specific_any. If solution A was implemented, at least it could be said no interposition overhead or local controls would have to be manufactured if you do not suspend or resume a transaction. > > > > C. Pass the control explicitly in the > >propagation_context. (This would then > > possibly make a remote call to get coordinator and > >terminator > > references that are already known locally.) > > > > Solution A is a workable solution for an rtf, Solution B addresses > >the > > issue more completely, and C well, I wouldn't vote for it. > > > > Comments, Opinions? Is Control as an object providing real value > >or is > > it just a struct in disguise complicating implementations? > > Having the Control as an object helps to add more behaviour in > >future (say when designing an > extended transaction model based on OTS), as against a simple > >struct. > Again, if Control is really going to represent the transaction, it must be used consistently in the spec. If a client has to create one locally, what additional functionality could it really have? The manufactured control would still have to redirect everything through the coordinator/terminator pair the OTS received in the propagation context. Cheers, Ted > Regards > Ram -- Ted McFadden tmcf@ooc.com.au Object Oriented Concepts http://www.ooc.com Suite 4 904 Stanley St. +61-7-3891-5744 East Brisbane 4169, QLD. Australia From: "Eric Newcomer" To: "Matthew Newhook" , "Blake Biesecker" Cc: "Ram Jeyaraman" , "Ted McFadden" , Subject: RE: Issue with CosTransactions::Control and implicit propagation implementations Date: Fri, 13 Oct 2000 12:05:57 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <20001012224639.A25406@ooc.com> Content-Type: text/plain; charset="us-ascii" X-UIDL: -]Me9(XNe9O\-!!(~~e9 Interposition should be required for two main reasons: -- historically OTS implementations have diverged according to various valid interetations of the spec and should necessarily not be required to change -- brigding disparate TP worlds is easier with an "agent" model such as interposition that allows the OTS 2PC primitives to be more easily mapped to other 2PC primitives (honoring the original goal of OTS -- or so I'm told -- to allow compatibility with existing TMs) Mainly it makes interoperability easier by hiding platform and TP system differences. Eric -----Original Message----- From: Matthew Newhook [mailto:matthew@ooc.com] Sent: Thursday, October 12, 2000 9:17 PM To: Blake Biesecker Cc: Ram Jeyaraman; Ted McFadden; ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Hi, On Thu, Oct 12, 2000 at 04:32:34PM -0700, Blake Biesecker wrote: > Matthew, > > I understand Ram's side of this conversation (and agree with what he > has said so far) but I'm struggling to get a handle on your point above. > Could you go into more detail about the scenario you are describing > above and when it would occur? One possible scenario could be when the user hasn't compiled the server side library into the executable? Besides why shouldl interposition be _required_ to write an interoperable implementation of the OTS? > Blake Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Fri, 13 Oct 2000 11:41:19 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Newcomer CC: Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: *nV!!+/$"!N43!!ehEe9 That is a great idea. Having such interoperability profile spelt out clearly in the spec would be very cool. Peter Furniss, would you please provide a pointer to your earlier proposal ? thank you, Ram Eric Newcomer wrote: > > Another possibility to consider is defining a profile of requirements > expressly for the purpose of achieving interoperability. This isn't really > defined today and gives rise to some of the issues discussed on this thread. > Peter Furniss a while back sketched this out, I'll try to find the email. > Basically he proposed requiring interposition for interoperability. That > would leave existing implementations of the spec undisturbed and provide a > framework for ensuring interoperability by defining a subset or specific > interpretation of the spec. > > Eric > > -----Original Message----- > From: Ted McFadden [mailto:tmcf@ooc.com.au] > Sent: Tuesday, October 10, 2000 9:50 PM > To: Ram Jeyaraman > Cc: issues@omg.org; ots-rtf@omg.org > Subject: Re: Issue with CosTransactions::Control and implicit > propagation implementations > > On Tue, Oct 10, 2000 at 11:54:49AM -0700, Ram Jeyaraman wrote: > > Hi Ram, > > A lot of discussion has already taken place, so I'll try not to be > (too) redundant but I do have a few comments: > > > Hello Ted, > > > > comments inlined.. > > > > Ted McFadden wrote: > > > > > > In summary, I'm asking the rtf to consider: > > > > > > 1. Whether the Current methods that use control are unecessarily > > > forcing implementations to interpose, use implementation_specific_any, > > > create local, non-interposed controls or other proprietary solutions. > > > > > > Some possible solutions: > > > > > > A. Provide: > > > Current::getCoordinator(), > > > Current::getTerminator() > > > > > > so that at least in many cases the ots runtime doesn't always > > > have to obtain a control object to provide what it already > > > knows. There are no versioning issues with Current since it is > > > locality constrained. > > > > > > (When and if Current::get_control() is called, the ots can > > > obtain the control reference at that point. It may still have > > > to use interposition to do this, but it can now be avoided some > > > of the time.) > > > > Avoiding creating the control object, but lazily creating one when > current.get_control() is invoked, > > seems like an optimization which vendor implementations (interposed or > non-interposed) could do > > today transparently. > > The immediate problem is not the lazy evaluation of get_control(). As > in the example I gave, you can't access the coordinator without going > through a control, even though the OTS runtime already has received > the control in the propagation_context with the request. So lazy, eval > or not, currently a control *always* has to be obtained somehow. > > I might not complain if that control were in the propagation context > but its not, but even if it was I end up with an RPC call to get an > object reference that is already locally known. > > The OTS spec exhibits a bit of a split personality here. Either control > should represent > the transaction or Coordinator/Terminator do. The problem arises because OTS > is not > quite self consistent in its implicit propagation model. > > > > > Adding new methods to the current object helps to only limit the need to > call on > > current.get_control(). But why ? Interposed or non-interposed, providing > (creating) a control object > > is not an impossibility and not an overhead. > > > > Forcing every program using OTS to either use interposition or to > manufacture control objects is an overhead. But if that's what's required > the spec should say so. > > > Having a control object serves to encapsulate the control information, and > avoids it from spilling > > over into Currrent (which should _theoretically_ have only > thread-transaction association info). > > > > If the control object is the proper interface for encapsulating the > transaction info, then why isn't it passed around in the propagation > context instead of the coordinator / terminator pair? > > > As an aside, implementation_specific_data provides ways to do > optimizations in homogenous > > environments. If an ORB detects that it is indeed talking to a different > vendor ORB (say through IOR > > info), then the propagation context should not use > implementation_specific_data, but use the > > standard OTS propagation context info in order to interoperate. > > > > If an implementation has to reply on implementation_specific_data it > cannot be interoperable with other vendor impls in a general sense. > > For example, the hack of putting the control reference in the > implementation_specific_any works if that control is received with a > request. > > If another vendor OTS doesn't send it, what is my OTS supposed to do? > It either has to manufacture control references or force use of > interposition. Which I have to say is a pretty poor interoperability > scenario. > > I really don't want to see us have to do an Interoperable OTS spec at > some point. ;) > > > > > > > B. Provide a struct representation of Control, and corresponding > > > operations on Current. > > > > > > The operations that would need `struct' equivalent are: > > > get_control() > > > suspend() > > > resume() > > > > This will break legacy applications. > > > > A clarification, I didn't say remove the old operations, just add the > new ones. Then we can say to customers, if you want to use the > `control' versions of the current methods, then you either run in a > homogeneous environment or you use interposition. > > If you don't want that overhead and would like interoperability with other > vendors, you use the struct versions. In which case our implementation > doesn't have to touch implementation_specific_any. > > If solution A was implemented, at least it could be said no > interposition overhead or local controls would have to be manufactured > if you do not suspend or resume a transaction. > > > > > > > C. Pass the control explicitly in the propagation_context. (This > would then > > > possibly make a remote call to get coordinator and terminator > > > references that are already known locally.) > > > > > > Solution A is a workable solution for an rtf, Solution B addresses the > > > issue more completely, and C well, I wouldn't vote for it. > > > > > > Comments, Opinions? Is Control as an object providing real value or is > > > it just a struct in disguise complicating implementations? > > > > Having the Control as an object helps to add more behaviour in future (say > when designing an > > extended transaction model based on OTS), as against a simple struct. > > > > Again, if Control is really going to represent the transaction, it > must be used consistently in the spec. If a client has to create one > locally, what additional functionality could it really have? > > The manufactured control would still have to redirect everything > through the coordinator/terminator pair the OTS received in the > propagation context. > > Cheers, > > Ted > > > Regards > > Ram > > -- > Ted McFadden tmcf@ooc.com.au > Object Oriented Concepts http://www.ooc.com > Suite 4 904 Stanley St. +61-7-3891-5744 > East Brisbane 4169, QLD. Australia Date: Mon, 16 Oct 2000 12:40:58 -0700 From: Blake Biesecker To: Matthew Newhook Cc: Ram Jeyaraman , Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001016124058.H923@gemstone.com> References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001011114943.C672@ooc.com.au> <39E63236.DAA2B9C@eng.sun.com> <20001012194408.A24134@ooc.com> <20001012163234.B526@gemstone.com> <20001012224639.A25406@ooc.com> <20001012190511.F526@gemstone.com> <20001013101005.A31637@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <20001013101005.A31637@ooc.com>; from matthew@ooc.com on Fri, Oct 13, 2000 at 10:10:05AM -0230 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: K!`d9+a@!!m0Ke9O@S!! On Fri, Oct 13, 2000 at 10:10:05AM -0230, Matthew Newhook wrote: > Hi, > > On Thu, Oct 12, 2000 at 07:05:11PM -0700, Blake Biesecker wrote: > > > [...] > > > One possible scenario could be when the user hasn't compiled the server > > > side library into the executable? > > > > I must be missing something. Interposition requires that a new Control > > be created that refers to a new Coordinator which needs to register > > itself with the Coordinator reference passed in by the PropagationContext. > > I'm not seeing how this requires anything less than creating a new Control > > and initialize it with the Coordinator and Terminator references in the > > PropagationContext. > > Where is the Control created? If there is NO interposition it must be > locally. Since Control is a full CORBA object the creation of a Control > and associated reference MUST require an object-adapter and hence a > server side. > I'm under the impression that interposition requires creating a Control object and a Coordinator object locally. From page 10-73 of the spec: Interposition When a transaction is propagated, the implicit context is exported and can be used by the importing Transaction Service implementation to create a new Control object which refers to a new (local) Coordinator. This technique, interposition, allows a surrogate to handle the functions of a coordinator in the importing domain. These coordinators act as subordinate coordinators. When interposition is performed, a single transaction is represented by multiple Coordinator objects. Interposition allows cooperating Transaction Services to share the responsibility for completing a transaction and can be used to minimize the number of network messages sent during the completion process. Interposition is required for a Transaction Service implementation to implement the is_same_transaction and hash_transaction operations as local method invocations, thus improving overall systems performance. An interposed coordinator registers as a participant in the transaction with the Coordinator identified in the PropagationContext of the received request. The relationships between coordinators in the transaction form a tree. The root coordinator is responsible for completing the transaction. Many implementations of the Transaction Service will want to perform interposition and thus create Control objects and subsequently Coordinator objects for each execution environment participating in the transaction. To create a new (local) Control, an importing Transaction Service uses the information in the propagation context to recreate a Control object using a TransactionFactory. Interposition must be complete before the get_control operation can complete in the target object. An object adaptor is one possible place to implement interposition. I don't understand your claim that interposition avoids the creation of full CORBA objects. > > > Besides why shouldl interposition be _required_ to write an interoperable > > > implementation of the OTS? > > > > > > > Because I don't see that it is needed at the moment. > > That's simply not true. Interposition (for all intents and purposes) is > required because there is no other way to create a new Control object. > > > And it seems to me that > > interposition can be less efficient if you are only expecting one Resource > > to register locally. > > Clients never register resources -- they are pure clients and only call > methods on servers. They may, however, want to suspect and resume the > transaction which requires the Control object. > So the OTS implementation somehow knows that the client will not register resources? How is this communicated? Regardless, where is the Control object in this scenario? Blake > > Blake > > Regards, Matthew > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Mon, 16 Oct 2000 22:34:03 -0230 From: Matthew Newhook To: Blake Biesecker Cc: Ram Jeyaraman , Ted McFadden , ots-rtf@omg.org Subject: Re: Issue with CosTransactions::Control and implicit propagation implementations Message-ID: <20001016223403.A13563@ooc.com> References: <20001009134246.B786@ooc.com.au> <39E365F9.6EB3BC0C@eng.sun.com> <20001011114943.C672@ooc.com.au> <39E63236.DAA2B9C@eng.sun.com> <20001012194408.A24134@ooc.com> <20001012163234.B526@gemstone.com> <20001012224639.A25406@ooc.com> <20001012190511.F526@gemstone.com> <20001013101005.A31637@ooc.com> <20001016124058.H923@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <20001016124058.H923@gemstone.com> Content-Type: text/plain; charset=us-ascii X-UIDL: 1EMe9ED2!!$M6e9%&ad9 Hi Blake, On Mon, Oct 16, 2000 at 12:40:58PM -0700, Blake Biesecker wrote: > [...] > I'm under the impression that interposition requires creating a Control > object and a Coordinator object locally. From page 10-73 of the spec: > > Interposition > >[...] > I don't understand your claim that interposition avoids the creation of full > CORBA objects. Interposition doesn't have to be local. You can interpose at any level -- in the current process, on the current machine, in the current intranet. > > [...] > > Clients never register resources -- they are pure clients and only > > call > > methods on servers. They may, however, want to suspect and resume > > the > > transaction which requires the Control object. > > So the OTS implementation somehow knows that the client will not > > register > resources? No. > How is this communicated? That's not what I'm saying. > Regardless, where is the Control object in this scenario? Hopefully the control object is the one that belongs to the OTS factory that the Coordinator and Terminator come from. > Blake Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725