Issue 3774: REQUIRES_UNSHARED transaction policy (ots-rtf) Source: ZeroC (Mr. Bernard Normier, bernard(at)zeroc.com) Nature: Uncategorized Issue Severity: Summary: It is not clear to me how a target with ALLOWS_UNSHARED or REQUIRES_UNSHARED can ever be invoked within a transaction: in a routed invocation, the last router will attempt a normal synchronous invocation on the target -- which will fail when the target's IOR has a transaction component carrying ALLOWS_UNSHARED or REQUIRES_UNSHARED. Resolution: Revised Text: Actions taken: August 15, 2000: received issue August 25, 2000: moved from OTS to Messaging RTF April 3, 2001: moved from the Messaging RTF to the OTS RTF Discussion: End of Annotations:===== From: "Bernard Normier" To: Cc: Subject: OTS issue: REQUIRES_UNSHARED transaction policy Date: Tue, 15 Aug 2000 13:04:31 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text X-UIDL: ]4d!!+f$!!6#(!!*P^d9 It is not clear to me how a target with ALLOWS_UNSHARED or REQUIRES_UNSHARED can ever be invoked within a transaction: in a routed invocation, the last router will attempt a normal synchronous invocation on the target -- which will fail when the target's IOR has a transaction component carrying ALLOWS_UNSHARED or REQUIRES_UNSHARED. Cheers, Bernard Date: Tue, 15 Aug 2000 11:49:08 -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: Bernard Normier CC: issues@omg.org, ots-rtf@omg.org Subject: Re: OTS issue: REQUIRES_UNSHARED transaction policy References: <006201c006da$e10767d0$6a85413f@boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Ti$!!E]]!!;,8e9#SIe9 Bernaud, Since the last router being a router will not do any invocation policy checks, i beleive. Neither will the server ORB know what invocation path was chosen. Only the client ORB can enforce the invocation policy checks and raise the appropriate exception. Regards Ram Bernard Normier wrote: > > It is not clear to me how a target with ALLOWS_UNSHARED or REQUIRES_UNSHARED > can ever be invoked within a transaction: in a routed invocation, the last > router will attempt a normal synchronous invocation on the target -- which > will fail when the target's IOR has a transaction component carrying > ALLOWS_UNSHARED or REQUIRES_UNSHARED. > > Cheers, > > Bernard From: "Bernard Normier" To: "Ram Jeyaraman" Cc: , References: <006201c006da$e10767d0$6a85413f@boston.amer.iona.com> <399990A4.820CEBA5@eng.sun.com> Subject: Re: OTS issue: REQUIRES_UNSHARED transaction policy Date: Tue, 15 Aug 2000 14:59:20 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text X-UIDL: BYi!!3J^d9'B`!!i5l!! Routers are regular ORB & OTS -based applications, aren't they? The last router's "client-side" will check the IOR of the target, and rejects a non-routed invocations when this IOR contains ALLOWS_UNSHARED or REQUIRES_UNSHARED. Cheers, Bernard ----- Original Message ----- From: "Ram Jeyaraman" To: "Bernard Normier" Cc: ; Sent: Tuesday, August 15, 2000 2:49 PM Subject: Re: OTS issue: REQUIRES_UNSHARED transaction policy > Bernaud, > > Since the last router being a router will not do any invocation >policy checks, i beleive. Neither > will the server ORB know what invocation path was chosen. > > Only the client ORB can enforce the invocation policy checks and >raise the appropriate exception. > > Regards > Ram > > Bernard Normier wrote: > > > > It is not clear to me how a target with ALLOWS_UNSHARED or >REQUIRES_UNSHARED > > can ever be invoked within a transaction: in a routed invocation, >the last > > router will attempt a normal synchronous invocation on the target >-- which > > will fail when the target's IOR has a transaction component >carrying > > ALLOWS_UNSHARED or REQUIRES_UNSHARED. > > > > Cheers, > > > > Bernard > Sender: jbiggar@corvette.floorboard.com Message-ID: <39999BDC.7B0DEDB9@floorboard.com> Date: Tue, 15 Aug 2000 12:37:00 -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: Ram Jeyaraman CC: Bernard Normier , issues@omg.org, ots-rtf@omg.org Subject: Re: OTS issue: REQUIRES_UNSHARED transaction policy References: <006201c006da$e10767d0$6a85413f@boston.amer.iona.com> <399990A4.820CEBA5@eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 7^:e9Q+""!J^,!!Q^jd9 Ram Jeyaraman wrote: > > Bernaud, > > Since the last router being a router will not do any invocation policy checks, i beleive. Neither > will the server ORB know what invocation path was chosen. > > Only the client ORB can enforce the invocation policy checks and raise the appropriate exception. This assumes, then that the router has a special relationship with the ORB that it is using, since it must be able to bypass any invocation policy checks. (Either that, or it must construct a new IOR that it uses for the invocation that does not have the invocation policy components.) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 16 Aug 2000 10:32:47 -0700 To: "Bernard Normier" , From: Edward Cobb Subject: Re: OTS issue: REQUIRES_UNSHARED transaction policy Cc: In-Reply-To: <006201c006da$e10767d0$6a85413f@boston.amer.iona.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: LC]!!SI%e9BIt is not clear to me how a target with ALLOWS_UNSHARED or REQUIRES_UNSHARED >can ever be invoked within a transaction: in a routed invocation, the last >router will attempt a normal synchronous invocation on the target -- which >will fail when the target's IOR has a transaction component carrying >ALLOWS_UNSHARED or REQUIRES_UNSHARED. > >Cheers, > >Bernard > > > > ************************************************************** Ed Cobb, Vice President, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Sat, 19 Aug 2000 20:31:29 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: OTS RTF Subject: Re: OTS issue: REQUIRES_UNSHARED transaction policy In-Reply-To: <39999BDC.7B0DEDB9@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: DIe!!(k$!!>Aod9O(=e9 On Tue, 15 Aug 2000, Jonathan Biggar wrote: > > Only the client ORB can enforce the invocation policy checks and raise the appropriate exception. > > This assumes, then that the router has a special relationship with the > ORB that it is using, since it must be able to bypass any invocation > policy checks. (Either that, or it must construct a new IOR that it > uses for the invocation that does not have the invocation policy > components.) Jon, you lost me there. Can you explain a bit more? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@corvette.floorboard.com Message-ID: <399ED312.56D9821A@floorboard.com> Date: Sat, 19 Aug 2000 11:33:54 -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: Michi Henning CC: OTS RTF Subject: Re: OTS issue: REQUIRES_UNSHARED transaction policy References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: -Oi!!?\gd9;##!!'hB!! Michi Henning wrote: > > On Tue, 15 Aug 2000, Jonathan Biggar wrote: > > > > Only the client ORB can enforce the invocation policy checks and raise the appropriate exception. > > > > This assumes, then that the router has a special relationship with the > > ORB that it is using, since it must be able to bypass any invocation > > policy checks. (Either that, or it must construct a new IOR that it > > uses for the invocation that does not have the invocation policy > > components.) > > Jon, you lost me there. Can you explain a bit more? If the router runs on top of a "normal" ORB, and if the object reference passed in the routed message contains an invocation policy that requires routed delivery, then the final router is stuck, since if it tries to make a direct invocation on the final target object reference, it will be routed again by the ORB. There are two ways to fix this: 1. The router needs to have a special hook into the ORB to tell it to ignore the invocation policy. or 2. The router needs to reconstruct a new reference without the invocation policy. But the object reference is opaque data to the final router, so it needs a hook here as well. (PI doesn't solve this currently. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Bill Binko To: "'Jonathan Biggar'" , Michi Henning Cc: OTS RTF Subject: RE: OTS issue: REQUIRES_UNSHARED transaction policy Date: Mon, 21 Aug 2000 14:19:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 'a3!!&EOe9E#9!!FN3!! Comments below: >From: Jonathan Biggar [mailto:jon@floorboard.com] >Michi Henning wrote: >> >> On Tue, 15 Aug 2000, Jonathan Biggar wrote: >> >> > > Only the client ORB can enforce the invocation policy >checks and raise the appropriate exception. >> > >> > This assumes, then that the router has a special >relationship with the >> > ORB that it is using, since it must be able to bypass any >invocation >> > policy checks. (Either that, or it must construct a new >IOR that it >> > uses for the invocation that does not have the invocation policy >> > components.) >> >> Jon, you lost me there. Can you explain a bit more? > >If the router runs on top of a "normal" ORB, and if the object >reference >passed in the routed message contains an invocation policy >that requires >routed delivery, then the final router is stuck, since if it tries to >make a direct invocation on the final target object reference, it >will >be routed again by the ORB. There are two ways to fix this: > >1. The router needs to have a special hook into the ORB to tell it >to >ignore the invocation policy. > >or > >2. The router needs to reconstruct a new reference without the >invocation policy. But the object reference is opaque data to >the final >router, so it needs a hook here as well. (PI doesn't solve this >currently. This is not a new concern, Jon. While the spec doesn't say how the Router handles this situation, the minute the (old) Requires_unshared was added to the spec, this problem became a concern. While I think it should be brought up in the Messaging RTF, I don't think this one should hold you guys up. It's important to realize that the need to make Messaging implementations independant of the ORB they run on is less of an issue than it is to OTS. While it is required that Routers talk to each other using GIOP-based protocols, and therefore interoperate with Routers from other ORBs, there is no requirement that they are written portably enough to run on other ORBs. This may change (particularly in Java, given the binary portability interfaces, etc) but I think this is an issue for Messaging, not OTS. Binko Date: Tue, 20 Mar 2001 20:02:58 -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 3774 proposed Core resolution Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: GMJe9g-f!!H:3!!'YV!! Issue 3774: REQUIRES_UNSHARED transaction policy (messaging-rtf) Click here for this issue's archive. Source: IONA (Mr. Bernard Normier, bernard.normier@iona.com) Nature: Uncategorized Issue Severity: Summary: It is not clear to me how a target with ALLOWS_UNSHARED or REQUIRES_UNSHARED can ever be invoked within a transaction: in a routed invocation, the last router will attempt a normal synchronous invocation on the target -- which will fail when the target's IOR has a transaction component carrying ALLOWS_UNSHARED or REQUIRES_UNSHARED. Resolution: Seems like an OTS issue, so hand over to OTS RTF Revised Text: Actions taken: Transfer to OTS RTF ________________________________________________________________________ Unless there is signficant objection to the above proposal, it will appear in the next Core RTF vote. Thanks, Jishnu.