Issue 587: Wrong Transaction on get_next_response (ots-rtf) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: How is application supposed to determine which of it"s outstanding requests violated the transaction discipline? Competing request is out parameter-unavailable in event of except Resolution: Revised Text: Actions taken: June 3, 1997: received issue October 20, 1999: moved from orb_revision to messaging-rtf April 3, 2001: moved from the Messaging RTF to OTS RTF Discussion: End of Annotations:===== Return-Path: Date: Tue, 3 Jun 1997 14:55:47 -0700 (PDT) From: Alan Snyder Reply-To: Alan Snyder Subject: Re: WrongTransaction on get_next_response To: "KCOLEMAN.US.ORACLE.COM" Cc: orb_revision@omg.org, ed.cobb@beasys.com >That's certainly what it says in the OTS spec, and as such, perhaps this isn't >a Core RTF issue, but throwing request-specific exceptions from >get_next_response is problematic: How is the application supposed to determine >which of it's outstanding requests violated the transaction discipline? I >believe the completing request is an out parameter and is therefore >unavailable in the event of an exception. Good question. I'm not sure how important this issue is. An application should not call get_next_response() within a transaction unless it is sure that all outstanding deferred requests were issued from that same transaction. If a stray response is picked up in this situation, the application probably won't even recognize it. Here's another question: If get_next_response() raises an exception, is the response discarded or is it still available? If the response is still available, the application can suspend the current transaction and call get_next_response() again to find out which response it was. Alan Sender: jis@fpk.hp.com Message-ID: <37B1B5CF.2B031501@fpk.hp.com> Date: Wed, 11 Aug 1999 13:41:35 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: ots-rtf@omg.org, orb_revision@omg.org Subject: Question about OTS Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 497e096ef73d7584e3c0ed25469bc903 Transaction Service experts: I would like to draw your attention to Issue 587, which is sitting on the Core RTF's plate at the moment. The entire issue and discussion is excerpted below for your reference. My specific question is: What do the existing Transaction Service implementations do in this case. This information would help us immensely in arriving at a reasonable resolution of this issue. It's been around unresolved a little too long for comfort. Thanks, Jishnu -- Jishnu Mukerji Chair CORBA Core RTF Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. _______________________ Issue 587 __________________________ Issue 587: Wrong Transaction on get_next_response (orb_revision) Source: Sun Microsystems (Mr. Alan Snyder, alan.snyder@eng.sun.com) Nature: Uncategorized Severity: Summary: How is application supposed to determine which of it's outstanding requests violated the transaction discipline? Competing request is out parameter-unavailable in event of except Resolution: Revised Text: Actions taken: June 3, 1997: received issue Discussion: End of Annotations:===== Return-Path: Date: Tue, 3 Jun 1997 14:55:47 -0700 (PDT) From: Alan Snyder Reply-To: Alan Snyder Subject: Re: WrongTransaction on get_next_response To: "KCOLEMAN.US.ORACLE.COM" Cc: orb_revision@omg.org, ed.cobb@beasys.com >That's certainly what it says in the OTS spec, and as such, perhaps this isn't >a Core RTF issue, but throwing request-specific exceptions from >get_next_response is problematic: How is the application supposed to determine >which of it's outstanding requests violated the transaction discipline? I >believe the completing request is an out parameter and is therefore >unavailable in the event of an exception. Good question. I'm not sure how important this issue is. An application should not call get_next_response() within a transaction unless it is sure that all outstanding deferred requests were issued from that same transaction. If a stray response is picked up in this situation, the application probably won't even recognize it. Here's another question: If get_next_response() raises an exception, is the response discarded or is it still available? If the response is still available, the application can suspend the current transaction and call get_next_response() again to find out which response it was. Alan Sender: jon@floorboard.com Message-ID: <37B1D878.91146B00@floorboard.com> Date: Wed, 11 Aug 1999 13:09:28 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: ots-rtf@omg.org, orb_revision@omg.org Subject: Re: Question about OTS References: <37B1B5CF.2B031501@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 52a4f46af588b25b43a0d6f143cbc1c3 Jishnu Mukerji wrote: > > Transaction Service experts: > > I would like to draw your attention to Issue 587, which is sitting > on > the Core RTF's plate at the moment. The entire issue and discussion > is > excerpted below for your reference. > > My specific question is: What do the existing Transaction Service > implementations do in this case. This information would help us > immensely in arriving at a reasonable resolution of this issue. It's > been around unresolved a little too long for comfort. _______________________ Issue 587 __________________________ > Issue 587: Wrong Transaction on > get_next_response > (orb_revision) > Source: Sun Microsystems (Mr. Alan Snyder, alan.snyder@eng.sun.com) > Nature: Uncategorized > Severity: > Summary: How is application supposed to determine which of it's > outstanding requests violated the transaction discipline? Competing > request is out parameter-unavailable in event of except This is a sticky problem, since it requires action on the part of the ORB core as well as the transaction service to "do the right thing". There appear to be two ways to get the "protocol" right here: 1. Make sure all outstanding deferred requests use the same transaction so that a thread that has that transaction "context" can call get_next_response() correctly. 2. Make sure that threads that call get_next_response() have no transaction "context" so that the context can be set by get_next_response() correctly. There is obviously some interaction with Portable Interceptors here, and I hope that the RFP submitters are considering this. Ultimately, this use of get_next_response() is outdated by the services of the Messaging specification, since the polling & callback approaches provide ever-so-much better application control over things. My inclination is to close this without change, and indicate that any client application that does not use one of the two "proper" protocols is simply broken. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jis@fpk.hp.com Message-ID: <380E2710.A8BBE7C4@fpk.hp.com> Date: Wed, 20 Oct 1999 16:33:20 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Juergen Boldt CC: orb_revision@omg.org, messaging-rtf@omg.org Subject: Issue 587 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: g]9!!C6,!!lDH!! To: Chris Smith Cc: ots-rtf@omg.org, messaging-rtf@omg.org Subject: Re: issues that need to be resolved before Oslo Message-ID: <20000328114206.C13707@gemstone.com> References: <20000327133040.C7825@gemstone.com> <38E05C2B.AEE2AEBA@uab.ericsson.se> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <38E05C2B.AEE2AEBA@uab.ericsson.se>; from uabcsru@uab.ericsson.se on Tue, Mar 28, 2000 at 09:15:55AM +0200 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: Y-Y!!S,Ne99#&!!fnl!! The last comment on issue 587 was to essentially deprecate get_next_response() in favor of polling & callback approaches. I'm not up to speed on the Messaging work, so if people could give me an idea if this idea is workable and if it has support that would be helpful. If this idea is workable, then I think the Messaging RTF could vote on this issue and the OTS RTF wouldn't need to get involved. If the proposed solution does not have support in the Messaging RTF, it looks like the solution to this problem may go beyond just OTS changes. Here is the last email that discussed this issue: ----------------------------------------------------------------------- > Issue 587: Wrong Transaction on > get_next_response > (orb_revision) > Source: Sun Microsystems (Mr. Alan Snyder, alan.snyder@eng.sun.com) > Nature: Uncategorized > Severity: > Summary: How is application supposed to determine which of it's > outstanding requests violated the transaction discipline? Competing > request is out parameter-unavailable in event of except This is a sticky problem, since it requires action on the part of the ORB core as well as the transaction service to "do the right thing". There appear to be two ways to get the "protocol" right here: 1. Make sure all outstanding deferred requests use the same transaction so that a thread that has that transaction "context" can call get_next_response() correctly. 2. Make sure that threads that call get_next_response() have no transaction "context" so that the context can be set by get_next_response() correctly. There is obviously some interaction with Portable Interceptors here, and I hope that the RFP submitters are considering this. Ultimately, this use of get_next_response() is outdated by the services of the Messaging specification, since the polling & callback approaches provide ever-so-much better application control over things. My inclination is to close this without change, and indicate that any client application that does not use one of the two "proper" protocols is simply broken. -- Jon Biggar Floorboard Software ----------------------------------------------------------------------- Blake On Tue, Mar 28, 2000 at 09:15:55AM +0200, Chris Smith wrote: > Issues 587 and 3004 in Messaging RTF also concern OTS, and > if you can find somebody who wants to put up a > proposal, I will gladly put it in the next vote. > > > Blake Biesecker wrote: > > > > Hello, All, > > > > We need to start getting aggressive with resolving issues, if > > we want to publish by Oslo. > > > > From what I can deduce (be warned, I haven't been following > > the Messaging RTF, so this is based on what I've seen in > > otsrtf mail), these are the open issues with regards to > > the Messaging RTF changes that we need to resolve: > > > > Issue 3417: TransactionalObject remnants > > Issue 3420: Component tag definition missing > > Issue 3421: CosTSInteroperation not specified > > Issue 3422: TranactionPolicyValue definition? > > Issue 3423: TransactionalPolicyComponent definition > > Issue 3424: Policy interrogation API? > > Issue 3425: IORs without policies? > > > > Please let me know if you feel that there are other > > Messaging related OTS issues that should be on the > > list above. > > > > I'd also like ideas on what people would like to see > > resolved with non-Messaging issues as well. Here is > > the beginnings of that list: > > > > (All issues that pass Vote 1) > > Issue 2580: rollback should raise HeuristicMixed, HeuristicHazard, > and HeuristicCommit > > Issue 2931: locality constraints > > > > Blake Sender: jbiggar@corvette.floorboard.com Message-ID: <38E1191D.70F82A17@floorboard.com> Date: Tue, 28 Mar 2000 12:42:05 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Blake Biesecker CC: Chris Smith , ots-rtf@omg.org, messaging-rtf@omg.org Subject: Re: issues that need to be resolved before Oslo References: <20000327133040.C7825@gemstone.com> <38E05C2B.AEE2AEBA@uab.ericsson.se> <20000328114206.C13707@gemstone.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 43Z!!Y:Le98KJe9R,De9 Blake Biesecker wrote: > > The last comment on issue 587 was to essentially deprecate > get_next_response() in favor of polling & callback approaches. Wow, that was me? I don't even remember writing that! :-) Trying to reconstruct my thoughts, I wasn't advocating deprecating get_next_response(), but rather documenting its limitations wrt the Wrong_Transaction danger and pointing to the messaging functionality as the "better way". -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 20 Mar 2001 19:10:47 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Cc: ots-rtf@omg.org Subject: Issue 587 proposed Core RTF resolution Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: #0#"!jW6e9BHXd9aX$!! Issue 587: Wrong Transaction on get_next_response (messaging-rtf) Click here for this issue's archive. Nature: Uncategorized Severity: Summary: How is application supposed to determine which of it"s outstanding requests violated the transaction discipline? Competing request is out parameter-unavailable in event of except Resolution: Clearly this is an OTS issue, so hand it over to OTS RTF Revised Text: Actions taken: Hand over to OTS RTF. __________________________________________________________________________ Unless there is signficant objection to this proposal, it will appear in the next Core RTF vote. Jishnu.