Issue 3611: Global-Scoped Invocations viz-a-viz ORB-scoped slot ids (interceptors-rtf) Source: Oracle (Dr. Harold Carr, Ph.D., nobody) Nature: Uncategorized Issue Severity: Summary: Invocations are global-scoped but slot ids are ORB-scoped. This does not work in the presence of multiple ORBS. Resolution: close issue, no change Revised Text: Actions taken: May 15, 2000: received issue January 9, 2001: closed issue Discussion: Through a rather lengthy email discussion it was determined that, while Harold may have presented a legitimate problem, changing how the slots work is not the solution. Harold raised another issue - 3626 - which revisits this from a different angle. End of Annotations:===== Date: Mon, 15 May 2000 11:24:24 -0700 (PDT) Message-Id: <200005151824.LAA08231@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org Subject: Global-Scoped Invocations viz-a-viz ORB-scoped slot ids Content-Type: text X-UIDL: Tb]d9@0'e91ZW!!28Fe9 Executive summary: Invocations are global-scoped but slot ids are ORB-scoped. This does not work in the presence of multiple ORBS. Example (in Java): Suppose the client does: ORB orb1 = ORB.init(...); ORB orb2 = ORB.init(...); NamingContext nc1= NamingContextHelper.narrow(orb1.resolve_initial_references("NameService")); NamingContext nc2= NamingContextHelper.narrow(orb2.resolve_initial_references("NameService")); Foo ref1 = nc1.resolve(...); Foo ref2 = nc2.resolve(...); someService.begin(); // e.g., begin transaction ref1.bar(...); ref2.bar(...); someService.end(); Discussion: Suppose the two ORBs instantiate different sets of interceptors. That could mean that the slot id(s) allocated to "someService" may differ. If the two ORBs are instantiated in different threads the slot ids could be different. If they are instantiated in the same thread they could end up duplicating themselves. When someService.begin() is invoked it would put some information in its slot. However, which slot, the one allocated in orb1 or orb2? Further, when ref1.bar is invoked it will use the slot allocated in orb1 while ref2.bar will use the slot allocated in orb2 (since the delegate will contain the ORB used during resolve_initial_references). Bottom line: Slots need to be global-scoped. Proposed solution: 1. Remove allocate_slot_id 2. Replace set_slot and get_slot (in all interfaces) with: void set_slot(String name, Any value); Any get_slot(String name) raise (InvalidSlot); Comments? Harold Date: Mon, 15 May 2000 16:10:52 -0230 From: Matthew Newhook To: Harold Carr Cc: interceptors-ftf@omg.org Subject: Re: Global-Scoped Invocations viz-a-viz ORB-scoped slot ids Message-ID: <20000515161051.A28955@ooc.com> References: <200005151824.LAA08231@shorter.eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <200005151824.LAA08231@shorter.eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: AAU!!^ID!!9_*!!90;!! Hi, On Mon, May 15, 2000 at 11:24:24AM -0700, Harold Carr wrote: > Executive summary: > > Invocations are global-scoped but slot ids are ORB-scoped. > This does not work in the presence of multiple ORBS. > > > Example (in Java): > > Suppose the client does: > > ORB orb1 = ORB.init(...); > ORB orb2 = ORB.init(...); > > > NamingContext nc1= > NamingContextHelper.narrow(orb1.resolve_initial_references("NameService")); > NamingContext nc2= > NamingContextHelper.narrow(orb2.resolve_initial_references("NameService")); > > > Foo ref1 = nc1.resolve(...); > Foo ref2 = nc2.resolve(...); > > > someService.begin(); // e.g., begin transaction > > ref1.bar(...); > ref2.bar(...); > > someService.end(); > > > Discussion: > > Suppose the two ORBs instantiate different sets of interceptors. > That could mean that the slot id(s) allocated to "someService" may > differ. I would certainly hope so. I think that there is a fundamental problem with your proposal -- ORBs are supposed to be seperate objects. Anything contained within the ORB should be seperate from any other ORB (like object references, services, etc). In the example above, assuming someService is a service on orb1 then the method call on ref1 should be transactional and the method call on ref2 should not be. I think that this is the correct behaviour. >[...] > Comments? > Harold 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: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA29288; Mon, 15 May 2000 14:37:24 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id OAA45070; Mon, 15 May 2000 14:57:19 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E0.00681DA7 ; Mon, 15 May 2000 14:57:13 -0400 X-Lotus-FromDomain: IBMUS To: Harold Carr cc: interceptors-ftf@omg.org Message-ID: <852568E0.00681829.00@d54mta04.raleigh.ibm.com> Date: Mon, 15 May 2000 14:56:57 -0400 Subject: Re: Global-Scoped Invocations viz-a-viz ORB-scoped slot ids Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: #gJ!!-J[!!cdi!!R8@e9 Harold Carr on 05/15/2000 01:24:24 PM > > > Executive summary: > > Invocations are global-scoped but slot ids are ORB-scoped. > This does not work in the presence of multiple ORBS. I disagree. Invocations are not global-scoped. Since they go through an ORB, they are scoped to an ORB. > > > Example (in Java): > > Suppose the client does: > > ORB orb1 = ORB.init(...); > ORB orb2 = ORB.init(...); > > > NamingContext nc1= > NamingContextHelper.narrow(orb1.resolve_initial_references("NameService")); > NamingContext nc2= > NamingContextHelper.narrow(orb2.resolve_initial_references("NameService")); > > > Foo ref1 = nc1.resolve(...); > Foo ref2 = nc2.resolve(...); > > > someService.begin(); // e.g., begin transaction Here's the crux of your problem. Where does "someService" come from? Either it comes from an ORB or it has to get something from an ORB, like a Current object. Either someService.begin must account for both ORBs, or there should be someService1 and someService2. (These things ARE called "ORB Services", aren't they?) > > ref1.bar(...); > ref2.bar(...); > > someService.end(); > > > Discussion: > > Suppose the two ORBs instantiate different sets of interceptors. Then you would have someService1 and someService2. > That could mean that the slot id(s) allocated to "someService" may > differ. > > If the two ORBs are instantiated in different threads the slot ids > could be different. If they are instantiated in the same thread > they > could end up duplicating themselves. > > When someService.begin() is invoked it would put some information in > its slot. However, which slot, the one allocated in orb1 or orb2? > Further, when ref1.bar is invoked it will use the slot allocated in > orb1 while ref2.bar will use the slot allocated in orb2 (since the > delegate will contain the ORB used during > resolve_initial_references). > > > Bottom line: > > Slots need to be global-scoped. > > > Proposed solution: > > 1. Remove allocate_slot_id > > 2. Replace set_slot and get_slot (in all interfaces) with: > > void set_slot(String name, Any value); > > Any get_slot(String name) raise (InvalidSlot); > > > Comments? > Harold > > Russell Butek butek@us.ibm.com Reply-To: From: "Nick Sharman" To: Subject: RE: Global-Scoped Invocations viz-a-viz ORB-scoped slot ids Date: Tue, 16 May 2000 12:37:23 +0100 Message-ID: <003101bfbf2b$1aac6d70$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <852568E0.00681829.00@d54mta04.raleigh.ibm.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: lpUd9'$F!!0$4!!^>Wd9 I think the perceived problem arises when different interceptor sets are associated with each ORB, but SomeService is common to both of them. In that case, it's quite likely that SomeService's ORBInitializer object will be allocated different slots by each of the ORBs. I think it's straightforward to solve this for Java: save allocated slot ids in the instance data of the ORBInitializer, not class static, and ensure the other Interceptor objects it creates & registers hold a link to the ORBInitializer object. This works whether the two ORBs are instances of the same ORBClass or of different ORBClass. For C++, the register_orb_initializer method is static, so we can only have one set of interceptors for all ORB instances anyway. Regards Nick > -----Original Message----- > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Sent: Monday, May 15, 2000 7:57 PM > To: Harold Carr > Cc: interceptors-ftf@omg.org > Subject: Re: Global-Scoped Invocations viz-a-viz ORB-scoped slot ids > > > > > > > Harold Carr on 05/15/2000 01:24:24 PM > > > > > > Executive summary: > > > > Invocations are global-scoped but slot ids are ORB-scoped. > > This does not work in the presence of multiple ORBS. > > I disagree. Invocations are not global-scoped. Since they go through an > ORB, they are scoped to an ORB. > > > > > > > Example (in Java): > > > > Suppose the client does: > > > > ORB orb1 = ORB.init(...); > > ORB orb2 = ORB.init(...); > > > > > > NamingContext nc1= > > > NamingContextHelper.narrow(orb1.resolve_initial_references("NameSe > rvice")); > > NamingContext nc2= > > > NamingContextHelper.narrow(orb2.resolve_initial_references("NameSe > rvice")); > > > > > > Foo ref1 = nc1.resolve(...); > > Foo ref2 = nc2.resolve(...); > > > > > > someService.begin(); // e.g., begin transaction > > Here's the crux of your problem. Where does "someService" come from? > Either it comes from an ORB or it has to get something from an ORB, like a > Current object. Either someService.begin must account for both ORBs, or > there should be someService1 and someService2. (These things ARE called > "ORB Services", aren't they?) > > > > > > ref1.bar(...); > > ref2.bar(...); > > > > someService.end(); > > > > > > Discussion: > > > > Suppose the two ORBs instantiate different sets of interceptors. > > Then you would have someService1 and someService2. > > > That could mean that the slot id(s) allocated to "someService" may > > differ. > > > > If the two ORBs are instantiated in different threads the slot ids > > could be different. If they are instantiated in the same thread they > > could end up duplicating themselves. > > > > When someService.begin() is invoked it would put some information in > > its slot. However, which slot, the one allocated in orb1 or orb2? > > Further, when ref1.bar is invoked it will use the slot allocated in > > orb1 while ref2.bar will use the slot allocated in orb2 (since the > > delegate will contain the ORB used during resolve_initial_references). > > > > > > Bottom line: > > > > Slots need to be global-scoped. > > > > > > Proposed solution: > > > > 1. Remove allocate_slot_id > > > > 2. Replace set_slot and get_slot (in all interfaces) with: > > > > void set_slot(String name, Any value); > > > > Any get_slot(String name) raise (InvalidSlot); > > > > > > Comments? > > Harold > > > > > > > Russell Butek > butek@us.ibm.com > > > Date: Tue, 16 May 2000 09:44:41 -0230 From: Matthew Newhook To: Nick Sharman Cc: interceptors-ftf@omg.org Subject: Re: Global-Scoped Invocations viz-a-viz ORB-scoped slot ids Message-ID: <20000516094441.E1130@ooc.com> References: <852568E0.00681829.00@d54mta04.raleigh.ibm.com> <003101bfbf2b$1aac6d70$5610a8c0@thumper.uk.peerlogic.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <003101bfbf2b$1aac6d70$5610a8c0@thumper.uk.peerlogic.com> Content-Type: text/plain; charset=us-ascii X-UIDL: J1,e9`R%!!U0He9KLnd9 Hi, On Tue, May 16, 2000 at 12:37:23PM +0100, Nick Sharman wrote: > I think the perceived problem arises when different interceptor sets are > associated with each ORB, but SomeService is common to both of them. In > that case, it's quite likely that SomeService's ORBInitializer object will > be allocated different slots by each of the ORBs. > > I think it's straightforward to solve this for Java: save allocated slot ids > in the instance data of the ORBInitializer, not class static, and ensure the > other Interceptor objects it creates & registers hold a link to the > ORBInitializer object. > > This works whether the two ORBs are instances of the same ORBClass or of > different ORBClass. > > For C++, the register_orb_initializer method is static, so we can only have > one set of interceptors for all ORB instances anyway. That's not true since I can register ORB initializers after some ORBs have been initialized. I can also look at arguments, or the ORB id to determine whether to create interceptors. Anyway, the real problem is that Harold wants services to be global, while in reality they are scoped to a particular ORB. In fact, I find it very strange that he wants global services when you consider the impact of that on the Java security model. > Regards > Nick 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 Reply-To: From: "Nick Sharman" To: "Matthew Newhook" Cc: Subject: RE: Global-Scoped Invocations viz-a-viz ORB-scoped slot ids Date: Tue, 16 May 2000 14:07:40 +0100 Message-ID: <003401bfbf37$b73f51f0$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <20000516094441.E1130@ooc.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: *\Wd9iKKe9\#4!!(US!! > -----Original Message----- > From: Matthew Newhook [mailto:matthew@ooc.com] > Sent: Tuesday, May 16, 2000 1:15 PM > To: Nick Sharman > Cc: interceptors-ftf@omg.org > Subject: Re: Global-Scoped Invocations viz-a-viz ORB-scoped slot ids > > > Hi, > > On Tue, May 16, 2000 at 12:37:23PM +0100, Nick Sharman wrote: > > I think the perceived problem arises when different interceptor sets are > > associated with each ORB, but SomeService is common to both of them. In > > that case, it's quite likely that SomeService's ORBInitializer > object will > > be allocated different slots by each of the ORBs. > > > > I think it's straightforward to solve this for Java: save > allocated slot ids > > in the instance data of the ORBInitializer, not class static, > and ensure the > > other Interceptor objects it creates & registers hold a link to the > > ORBInitializer object. > > > > This works whether the two ORBs are instances of the same ORBClass or of > > different ORBClass. > > > > For C++, the register_orb_initializer method is static, so we > can only have > > one set of interceptors for all ORB instances anyway. > > That's not true since I can register ORB initializers after some ORBs have > been initialized. I can also look at arguments, or the ORB id to > determine whether to create interceptors. > Hmmm, yes I guess so. I'd forgotten the ORB id & args stuff. So register_orb_initializer has to stash the supplied reference somewhere, and whenever ORB_init is called it has to call pre_init/post_init on each reference stashed so far. Since (as you point out) services should be scoped by ORB, this means that the service must maintain a map from orb_id to some data structures each containing one ORB instance's allocated slot ids and anything else it needs. Is that sensible? > Anyway, the real problem is that Harold wants services to be global, > while in reality they are scoped to a particular ORB. In fact, I > find it > very strange that he wants global services when you consider the > impact > of that on the Java security model. > Agreed. I guess it's possible for the different instances to > cooperate 'under the hood' via static data, but the initial references should be distinct in each ORB's instance of the service interceptor. > > Regards > > Nick > > 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 > Regards Nick Date: Tue, 16 May 2000 10:39:44 -0230 From: Matthew Newhook To: Nick Sharman Cc: interceptors-ftf@omg.org Subject: Re: Global-Scoped Invocations viz-a-viz ORB-scoped slot ids Message-ID: <20000516103944.A2059@ooc.com> References: <20000516094441.E1130@ooc.com> <003401bfbf37$b73f51f0$5610a8c0@thumper.uk.peerlogic.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <003401bfbf37$b73f51f0$5610a8c0@thumper.uk.peerlogic.com> Content-Type: text/plain; charset=us-ascii X-UIDL: Q$Rd9EQMe9`$M!!4b/!! Hi, On Tue, May 16, 2000 at 02:07:40PM +0100, Nick Sharman wrote: > > That's not true since I can register ORB initializers after some ORBs have > > been initialized. I can also look at arguments, or the ORB id to > > determine whether to create interceptors. > > > Hmmm, yes I guess so. I'd forgotten the ORB id & args stuff. So > register_orb_initializer has to stash the supplied reference somewhere, and > whenever ORB_init is called it has to call pre_init/post_init on each > reference stashed so far. Since (as you point out) services should be > scoped by ORB, this means that the service must maintain a map from orb_id > to some data structures each containing one ORB instance's allocated slot > ids and anything else it needs. Is that sensible? Personally, I think thats the wrong way to think about it because that viewpoint implies a static view of a service. I would rather think of the services would create instances of the the specific implementation of the interceptors, currents, and IOR interceptors which are then attached to the ORB. I don't see why you need any sort of map to ORB-id (especially in light of the fact that there is no ORB id in Java). > > Anyway, the real problem is that Harold wants services to be global, > > while in reality they are scoped to a particular ORB. In fact, I find it > > very strange that he wants global services when you consider the impact > > of that on the Java security model. > > > Agreed. I guess it's possible for the different instances to cooperate > 'under the hood' via static data, but the initial references should be > distinct in each ORB's instance of the service interceptor. Possible, I guess. The only reason that I can think to do this is if you want to do some sort of in-process optimizations. However, I haven't thought about that enough to determine whether there is sufficient information to do such optimizations. > Regards > Nick Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Reply-To: From: "Nick Sharman" To: "Matthew Newhook" Cc: Subject: RE: Global-Scoped Invocations viz-a-viz ORB-scoped slot ids Date: Tue, 16 May 2000 14:57:48 +0100 Message-ID: <003501bfbf3e$b7c9da80$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <20000516103944.A2059@ooc.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: C=&e9(J_d9hkQ!!$^!e9 Matthew, > -----Original Message----- > From: Matthew Newhook [mailto:matthew@ooc.com] > Sent: Tuesday, May 16, 2000 2:10 PM > To: Nick Sharman > Cc: interceptors-ftf@omg.org > Subject: Re: Global-Scoped Invocations viz-a-viz ORB-scoped slot ids > > > Hi, > > On Tue, May 16, 2000 at 02:07:40PM +0100, Nick Sharman wrote: > > > That's not true since I can register ORB initializers after > some ORBs have > > > been initialized. I can also look at arguments, or the ORB id to > > > determine whether to create interceptors. > > > > > Hmmm, yes I guess so. I'd forgotten the ORB id & args stuff. So > > register_orb_initializer has to stash the supplied reference > somewhere, and > > whenever ORB_init is called it has to call pre_init/post_init on each > > reference stashed so far. Since (as you point out) services should be > > scoped by ORB, this means that the service must maintain a map > from orb_id > > to some data structures each containing one ORB instance's > allocated slot > > ids and anything else it needs. Is that sensible? > > Personally, I think thats the wrong way to think about it because that > viewpoint implies a static view of a service. I would rather think of > the services would create instances of the the specific implementation of > the interceptors, currents, and IOR interceptors which are then attached > to the ORB. I don't see why you need any sort of map to ORB-id > (especially in light of the fact that there is no ORB id in Java). > I don't think we disagree here! My thoughts (above) were only relevant to C++, where the registration function is static and (I assume) gets called once per service from application level - 21.7.3.1 doesn't give much detail!. So inside pre_init/post_init, which presumably get called once per ORB_init call, the service must arrange to keep the per-ORB slot ids, references and anything else separate for each ORB instance. In Java, I think it's ok to use the per-ORB instance of the ORBInitializer object. Regards Nick Date: Mon, 15 May 2000 12:04:44 -0700 (PDT) Message-Id: <200005151904.MAA12916@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org Subject: Slots need to be globally scoped Content-Type: text X-UIDL: 9kP!!_6#e9;S9e9DQ6!! Thanks to Russell and Matthew for refining my initial mail. It was mistaken to say that invocation are global scoped. However, the problem remains. If a client does: someService.begin(); ref1.bar(); ref2.bar(); someService.eng(); then some "someService" may be talking to different slots than ref1 and/or ref2. Slots need to be globally scoped. Harold Date: Mon, 15 May 2000 17:03:10 -0230 From: Matthew Newhook To: Harold Carr Cc: interceptors-ftf@omg.org Subject: Re: Slots need to be globally scoped Message-ID: <20000515170310.B29529@ooc.com> References: <200005151904.MAA12916@shorter.eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <200005151904.MAA12916@shorter.eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: hpDe9pKo!!e\a!!'L'e9 Hi, On Mon, May 15, 2000 at 12:04:44PM -0700, Harold Carr wrote: > Thanks to Russell and Matthew for refining my initial mail. > It was mistaken to say that invocation are global scoped. > However, the problem remains. If a client does: > > someService.begin(); > > ref1.bar(); > ref2.bar(); > > someService.eng(); > > > then some "someService" may be talking to different slots > than ref1 and/or ref2. Slots need to be globally scoped. I still think this is wrong. Object references are bound to ORBs. Therefore the slots are scoped to the ORB. > Harold 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: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA30922; Mon, 15 May 2000 15:26:53 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id PAA42980; Mon, 15 May 2000 15:39:17 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E0.006BF688 ; Mon, 15 May 2000 15:39:14 -0400 X-Lotus-FromDomain: IBMUS To: Harold Carr cc: interceptors-ftf@omg.org Message-ID: <852568E0.006BF0DE.00@d54mta04.raleigh.ibm.com> Date: Mon, 15 May 2000 15:38:05 -0400 Subject: Re: Slots need to be globally scoped Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: _Q/!!J;&!!%""e9-[ on 05/15/2000 02:04:44 PM To: interceptors-ftf@omg.org cc: Subject: Slots need to be globally scoped Thanks to Russell and Matthew for refining my initial mail. It was mistaken to say that invocation are global scoped. However, the problem remains. If a client does: someService.begin(); ref1.bar(); ref2.bar(); someService.eng(); then some "someService" may be talking to different slots than ref1 and/or ref2. Slots need to be globally scoped. Harold X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 15 May 2000 15:44:45 -0400 (EDT) From: Polar Humenn To: Harold Carr cc: interceptors-ftf@omg.org Subject: Re: Slots need to be globally scoped In-Reply-To: <200005151904.MAA12916@shorter.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 2j(!!,[6e9*End9Pid!! On Mon, 15 May 2000, Harold Carr wrote: > Thanks to Russell and Matthew for refining my initial mail. > It was mistaken to say that invocation are global scoped. > However, the problem remains. If a client does: > > someService.begin(); > > ref1.bar(); > ref2.bar(); > > someService.eng(); > > > then some "someService" may be talking to different slots > than ref1 and/or ref2. Slots need to be globally scoped. There must be a scope for interceptors, and I thought that scope was the ORB. The fact that you have an application which uses two ORB instances, means that you must explicitly manage the slots within the interceptor. You should technically have two interceptor instances, correct? There is nothing that states that the call to ref1.bar() and ref2.bar() happen on the same thread as far as the ORBs are concerned. Physically they may, because of language constraints and semantics, but the one ORB will not know the thread space of another. I guess assigning slot id's might enable ORB thread space sharing, but is that a good idea? I mean, we have to draw a boundary around somethings, eh? If you are looking to correlate invocations between ORBS and you had the ability to set the slot id's, then what if ref1.bar() calls ref2.bar()? What slot id should it use? Cheers, -Polar > > Harold > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Mon, 15 May 2000 13:20:30 -0700 (PDT) Message-Id: <200005152020.NAA22306@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org Subject: Re: Slots need to be globally scoped Content-Type: text X-UIDL: dOB!!^)/e9/Obd9Bl;e9 Russell, Matthew and Polar (et. al), Without global-scoped slot identifiers the programming model becomes very restricted. Suppose a client thread has its hands on two references but that those references have different ORBs associated with their delegate. The client does: someService.begin(); ref1.bar(); ref2.bar(); someService.end(); someService.begin will use the PICurrent for the current thread and the slot allocated to it during orb init. Somehow, the service remembers this slot id for use during "begin". Since ref1 and ref2 have different orbs in their delegate, the interceptors executed during the course of ref1.bar will be different instantiations (and possibly a different set) than those run in the course of ref2.bar. Let's say that the service is transactions and both ref1 and ref2 are transactional. However, if the transaction service associated with, say, ref2's ORB has a different slot id than the one used by someService.begin(), then it will be left out of the transaction. Without global-scoped slot identifiers it would restrict the model of usage such that a programmer would need to know where ALL their references came from (probably intractable). With global-scoped slot identifiers it is simple. Regardless of the orb the slot ID may be found. Interceptors are still ORB-scoped. PICurrent is still thread-scoped. The only change is that slots work when multiple ORBs are present. Harold Date: Mon, 15 May 2000 16:31:47 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr CC: interceptors-ftf@omg.org Subject: Re: Slots need to be globally scoped References: <200005152020.NAA22306@shorter.eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: >_5!!)%&e9)3$!!OC!e9 Harold Carr wrote: > > Russell, Matthew and Polar (et. al), > > Without global-scoped slot identifiers the programming model > becomes very restricted. Suppose a client thread has its hands > on two references but that those references have different ORBs > associated with their delegate. The client does: > > someService.begin(); > > ref1.bar(); > ref2.bar(); > > someService.end(); > > someService.begin will use the PICurrent for the current thread > and the slot allocated to it during orb init. Somehow, the service > remembers this slot id for use during "begin". > > Since ref1 and ref2 have different orbs in their delegate, the > interceptors executed during the course of ref1.bar will be different > instantiations (and possibly a different set) than those run in the > course of ref2.bar. That is what I would expect. > > Let's say that the service is transactions and both ref1 and ref2 > are > transactional. However, if the transaction service associated > with, say, ref2's ORB has a different slot id than the one used > by someService.begin(), then it will be left out of the transaction. If someService came from ref1's ORB (i.e. from resolve_initial_references()), then the invocation is part of the transaction started with someService. If someService came from ref2's ORB, then the invocation is not part of the transaction started with someService. > > Without global-scoped slot identifiers it would restrict the model > of usage such that a programmer would need to know where ALL their > references came from (probably intractable). The references created with different ORBs are not interchangable. Users must keep track of them if they are using multiple ORBs. This doesn't turn out to be a big problem though, since most applications only use a single ORB, and when multiple ORBs are in use, they are being used independently by different parts of the program. > > With global-scoped slot identifiers it is simple. Regardless > of the orb the slot ID may be found. But using ORB1's transaction for an invocation made on ORB2's object would be a serious bug, in my opinion. > > Interceptors are still ORB-scoped. PICurrent is still > thread-scoped. > The only change is that slots work when multiple ORBs are present. Our view is that Currents, and therefore slots, must remain ORB-scoped. Basically, each ORB has a distinct Current instance for any particular ORB service. > > Harold -Bob X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 15 May 2000 16:39:22 -0400 (EDT) From: Polar Humenn To: Harold Carr cc: interceptors-ftf@omg.org Subject: Re: Slots need to be globally scoped In-Reply-To: <200005152020.NAA22306@shorter.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: mYI!!f$F!!XK!e9P/md9 On Mon, 15 May 2000, Harold Carr wrote: > Interceptors are still ORB-scoped. PICurrent is still thread-scoped. > The only change is that slots work when multiple ORBs are present. I thought the PICurrent is ORB scoped AND thread scoped? Does PICurrent span across different ORBs? How does that happen? -Polar Date: Mon, 15 May 2000 14:06:13 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Harold Carr , interceptors-ftf@omg.org Subject: Re: Slots need to be globally scoped References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 53i!!CCNe9+@n!!Bd:e9 Maybe this needs clarification. My take is that there is a PICurrent per thread (outside of interceptor points). So, within the same thread, orb1 = orb.init(...); orb2 = orb.init(...); pic1 = orb.resolve_initial_reference("PICurrent"); pic2 = orb.resolve_initial_reference("PICurrent"); would mean that pic1 and pic2 contain references to the same current. If that is not the case could someone point me to the place in the spec which says otherwise. Thanks, Harold Polar Humenn wrote: > > On Mon, 15 May 2000, Harold Carr wrote: > > > Interceptors are still ORB-scoped. PICurrent is still thread-scoped. > > The only change is that slots work when multiple ORBs are present. > > I thought the PICurrent is ORB scoped AND thread scoped? > > Does PICurrent span across different ORBs? How does that happen? > > -Polar X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 15 May 2000 17:22:22 -0400 (EDT) From: Polar Humenn To: Harold Carr cc: Harold Carr , interceptors-ftf@omg.org Subject: Re: Slots need to be globally scoped In-Reply-To: <392066C5.345A81DC@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 9mIe9CVD!!7C*!!],!"! I don't know where in the spec it says otherwise, but I think you have a chicken and egg problem here. If you don't have an ORB (yet), how can you have a PICurrent object? Is there some scope greater than the ORB that is defined? The second ORB when it is created is supposed to know the other PICurrent object was created and go get it instead of creating a different one? If it gets it, from where? Is there a PICurrent repository? Can a PICurrent Object, which is a CORBA object, exist without an ORB first? Cheers, -Polar On Mon, 15 May 2000, Harold Carr wrote: > Maybe this needs clarification. My take is that there > is a PICurrent per thread (outside of interceptor points). > So, within the same thread, > > orb1 = orb.init(...); > orb2 = orb.init(...); > > pic1 = orb.resolve_initial_reference("PICurrent"); > pic2 = orb.resolve_initial_reference("PICurrent"); > > would mean that pic1 and pic2 contain references > to the same current. If that is not the case could > someone point me to the place in the spec which > says otherwise. > > Thanks, > Harold > > > Polar Humenn wrote: > > > > On Mon, 15 May 2000, Harold Carr wrote: > > > > > Interceptors are still ORB-scoped. PICurrent is still > thread-scoped. > > > The only change is that slots work when multiple ORBs are > present. > > > > I thought the PICurrent is ORB scoped AND thread scoped? > > > > Does PICurrent span across different ORBs? How does that happen? > > > > -Polar > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Slots need to be globally scoped Date: Mon, 15 May 2000 18:42:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: `fZd9fSXd9=,*!!/7jd9 Harold, Perhaps I am missing your point, but none of the currents, including PICurrent are per-thread. The reference obtained by calling resolve_initial_references("PICurrent") may be shared among threads. The operations on it act on per-thread data. Specifically, each orb's PICurrent should have a set of slots for each thread. Because slot ids are dynamically assigned, your implementation may choose to have the multiple PICurrent instances cooperate in assigning slot ids in such a way that there is no overlap of slot ids between multiple orbs. But that is an implementation choice. Paul > -----Original Message----- > From: Harold Carr [mailto:harold.carr@sun.com] > Sent: Monday, May 15, 2000 5:06 PM > To: Polar Humenn > Cc: Harold Carr; interceptors-ftf@omg.org > Subject: Re: Slots need to be globally scoped > > > Maybe this needs clarification. My take is that there > is a PICurrent per thread (outside of interceptor points). > So, within the same thread, > > orb1 = orb.init(...); > orb2 = orb.init(...); > > pic1 = orb.resolve_initial_reference("PICurrent"); > pic2 = orb.resolve_initial_reference("PICurrent"); > > would mean that pic1 and pic2 contain references > to the same current. If that is not the case could > someone point me to the place in the spec which > says otherwise. > > Thanks, > Harold > > > Polar Humenn wrote: > > > > On Mon, 15 May 2000, Harold Carr wrote: > > > > > Interceptors are still ORB-scoped. PICurrent is still > thread-scoped. > > > The only change is that slots work when multiple ORBs are present. > > > > I thought the PICurrent is ORB scoped AND thread scoped? > > > > Does PICurrent span across different ORBs? How does that happen? > > > > -Polar > Reply-To: From: "Nick Sharman" To: "Harold Carr" , Subject: RE: Slots need to be globally scoped Date: Tue, 16 May 2000 13:07:30 +0100 Message-ID: <003201bfbf2f$4f27cdc0$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <200005151904.MAA12916@shorter.eng.sun.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: $D/!!Bc3e9L]%e9(pN!! > -----Original Message----- > From: Harold Carr [mailto:harold.carr@eng.sun.com] > Sent: Monday, May 15, 2000 8:05 PM > To: interceptors-ftf@omg.org > Subject: Slots need to be globally scoped > > > Thanks to Russell and Matthew for refining my initial mail. > It was mistaken to say that invocation are global scoped. > However, the problem remains. If a client does: > > someService.begin(); > > ref1.bar(); > ref2.bar(); > > someService.eng(); > > > then some "someService" may be talking to different slots > than ref1 and/or ref2. Slots need to be globally scoped. > > Harold > > Where does the object someService come from? If you need to make some SomeService operations visible at the application level, I think the best (only?) way is to register an object as an initial service. The service should register a different instance with each ORB. Harold's example does raise another issue, assuming "eng" is a typo for "end": do we need some way of cleaning up interceptors during orb.shutdown? Regards Nick Reply-To: From: "Nick Sharman" To: Subject: RE: Slots need to be globally scoped Date: Tue, 16 May 2000 13:17:31 +0100 Message-ID: <003301bfbf30$b59a31a0$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <392066C5.345A81DC@sun.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: h@ -----Original Message----- > From: Harold Carr [mailto:harold.carr@sun.com] > > Maybe this needs clarification. My take is that there > is a PICurrent per thread (outside of interceptor points). > So, within the same thread, > > orb1 = orb.init(...); > orb2 = orb.init(...); > > pic1 = orb.resolve_initial_reference("PICurrent"); > pic2 = orb.resolve_initial_reference("PICurrent"); > > would mean that pic1 and pic2 contain references > to the same current. If that is not the case could > someone point me to the place in the spec which > says otherwise. > > Thanks, > Harold > The assignments to pic1 & pic2 are incorrect, since resolve_initial_reference isn't a static method. They should be: pic1 = orb1.resolve_initial_reference("PICurrent"); pic2 = orb2.resolve_initial_reference("PICurrent"); and should return _different_ PICurrent instances, one per orb. That should go for _any_ initial service: the SomeService interceptor should register different objects for each of its instantiations and not use class static storage. Regards Nick From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA29080; Tue, 16 May 2000 08:14:38 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id IAA40384; Tue, 16 May 2000 08:33:44 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E1.00450043 ; Tue, 16 May 2000 08:33:40 -0400 X-Lotus-FromDomain: IBMUS To: nick.sharman@peerlogic.com cc: interceptors-ftf@omg.org Message-ID: <852568E1.0044FBD3.00@d54mta04.raleigh.ibm.com> Date: Tue, 16 May 2000 08:33:27 -0400 Subject: RE: Slots need to be globally scoped Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: hOSd9lXY!!b8A!!,Lod9 "Nick Sharman" on 05/16/2000 07:07:30 AM > Harold's example does raise another issue, assuming "eng" is a typo for > "end": do we need some way of cleaning up interceptors during orb.shutdown? I believe issue 3435 already covers this question. > > Regards > Nick > Russell Butek butek@us.ibm.com From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA35980; Tue, 16 May 2000 08:19:38 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id IAA47066; Tue, 16 May 2000 08:38:45 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E1.004573E6 ; Tue, 16 May 2000 08:38:36 -0400 X-Lotus-FromDomain: IBMUS To: Harold Carr cc: interceptors-ftf@omg.org Message-ID: <852568E1.00457195.00@d54mta04.raleigh.ibm.com> Date: Tue, 16 May 2000 08:38:28 -0400 Subject: Re: Slots need to be globally scoped Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: ]PI!!H7fd9 on 05/15/2000 04:06:13 PM To: Polar Humenn cc: Harold Carr , interceptors-ftf@omg.org Subject: Re: Slots need to be globally scoped Maybe this needs clarification. My take is that there is a PICurrent per thread (outside of interceptor points). So, within the same thread, orb1 = orb.init(...); orb2 = orb.init(...); pic1 = orb.resolve_initial_reference("PICurrent"); pic2 = orb.resolve_initial_reference("PICurrent"); would mean that pic1 and pic2 contain references to the same current. If that is not the case could someone point me to the place in the spec which says otherwise. Thanks, Harold Polar Humenn wrote: > > On Mon, 15 May 2000, Harold Carr wrote: > > > Interceptors are still ORB-scoped. PICurrent is still thread-scoped. > > The only change is that slots work when multiple ORBs are present. > > I thought the PICurrent is ORB scoped AND thread scoped? > > Does PICurrent span across different ORBs? How does that happen? > > -Polar Date: Tue, 16 May 2000 10:33:25 -0700 (PDT) Message-Id: <200005161733.KAA10793@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org Subject: ORB-scoped slots ids Content-Type: text X-UIDL: cY)!! To: Harold Carr cc: interceptors-ftf@omg.org Subject: Re: ORB-scoped slots ids In-Reply-To: <200005161733.KAA10793@shorter.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: pANd9&SY!!P_S!!^9_!! On Tue, 16 May 2000, Harold Carr wrote: > > The responses to the issue I raised all seem to assume that one has > complete control all orb instantiations and knowledge of where > all references were obtained. We have a use case (from a real > client) > that shows this assumption to be false. > > I will try again via an example. > > Suppose the client only does one explicit ORB.init: > > ORB orbX = ORB.init(...); > > During orbX initialization some service obtains slot id N and > registers its interceptors. It also registers a client side service > initial reference with naming. > > Continuing, the client obtains two references, one directly via > naming > the other through some naming facade (such as JNDI): > > Foo ref1 = > FooHelper.narrow(NamingContextHelper.narrow(orbX.resolve_initial_references("NameService")).resolve(...)); > > Foo ref2 = JNDI.lookup(...); // fake syntax of course > > The JNDI implementation nows nothing of the orbX instantiated by the > client. Instead, it internally instantiates its own orbY to obtain > the initial naming context. The JNDI implementation may choose to > add > more ORBInitializers before instantiating the orbY. In this case, > since no order is presumed, someService may end up with slot id Q in > this ORB scope. > > Now the client does a reasonable set of calls: > > someService = orb.resolve_initial_reference("someService"); // > narrow etc. > > someService.begin(); > > ref1.bar(...); > ref2.bar(...); > > someService.end(); > > The service begin puts some info in slot N. ref1.bar() works fine > since they all agree on slot N. However, the interceptors invoked > when ref2.bar() runs will look in slot Q. That's the problem. I think this is quite a bizzare application of using ORBs. And if you want that kind of functionality, the JNDI should be able to take the ORB in question as an argument so that you are all on the same page. The other way to do this, is to get rid of the ORB init all together, and just make it the operating system, but I think we are quite a few years of research away from that, although :) we're looking at it. :) > > Harold > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Tue, 16 May 2000 11:15:01 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Harold Carr , interceptors-ftf@omg.org Subject: Re: ORB-scoped slots ids References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: opCe9FSU!!6Bb!!KUT!! > I think this is quite a bizzare application of using ORBs. And if you want > that kind of functionality, the JNDI should be able to take the ORB in > question as an argument so that you are all on the same page. The only thing bizarre is my forced example using both resolve directly and JNDI. Remove the use of resolve_initial_references and just use JNDI. The problem remains. A client would reasonably expect to be able to get something out of naming and have the services work. H X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 16 May 2000 14:24:01 -0400 (EDT) From: Polar Humenn To: Harold Carr cc: Harold Carr , interceptors-ftf@omg.org Subject: Re: ORB-scoped slots ids In-Reply-To: <39219025.C554EE1D@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: )MC!!6PLe9hd-e9OUPe9 On Tue, 16 May 2000, Harold Carr wrote: > > > I think this is quite a bizzare application of using ORBs. And if you want > > that kind of functionality, the JNDI should be able to take the ORB in > > question as an argument so that you are all on the same page. > > The only thing bizarre is my forced example using both resolve > directly and JNDI. Remove the use of resolve_initial_references and > just use JNDI. The problem remains. A client would reasonably expect > to be able to get something out of naming and have the services work. I don't see it. Why do the interceptors of the two threads in the ORB need to collaborate? You are assuming some cross functionality across ORBs now facilitiated by interceptors, whose instances are scoped only to the ORB they are registered with. Can you give a concrete example of what this kind of functionality is needed for to give at least me a better understanding of the requirement? i.e. what would an interceptor of ref2.bar() need to know that ref1.bar() had done? I think "global" scoping is a bad idea. If this kind of functionality is warranted, I believe then there should be a concrete model of scope that is greater than the ORB. That would lift the threading models from the ORB onto something else. Could get crazy. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Tue, 16 May 2000 11:43:35 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Harold Carr , interceptors-ftf@omg.org Subject: Re: ORB-scoped slots ids References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: R%5e90g8!!9cld9Z<`!! Polar, There is only one thread in my example. There is no need to communicate between interceptors or refs or whatever. There just needs to be agreement on slot ids. Let me reduce my example as far as possible: ORB orbX = ORB.init(...); Foo ref = JNDI.lookup(...); // fake syntax of course someService = orbX.resolve_initial_reference("someService"); // narrow etc. someService.begin(); ref.bar(...); someService.end(); A user would reasonable expect that the service would indeed service ref.bar(). However, since "ref" was obtained from a naming facade which internally instantiates its own orb, the slot id for the service could be different in that orb. Therefore ref.bar() would be left out of the service. The above is very reasonable existing code. The only global thing I am suggesting is slot_ids themselves - a string - just like URLs are global (by convention). Harold From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA19404; Tue, 16 May 2000 15:16:20 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id PAA45838; Tue, 16 May 2000 15:25:34 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E1.006AB4A9 ; Tue, 16 May 2000 15:25:30 -0400 X-Lotus-FromDomain: IBMUS To: Harold Carr cc: interceptors-ftf@omg.org Message-ID: <852568E1.006AB399.00@d54mta04.raleigh.ibm.com> Date: Tue, 16 May 2000 15:25:25 -0400 Subject: Re: ORB-scoped slots ids Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: O@od9f<'e9T-k!!#YYd9 This is bigger than just slots and interceptors. We just happen to see it with slots. The problem with this scenario is that there is an ORB that the application doesn't know about (or if you prefer, an ORB that JNDI doesn't know about). That can be dangerous. - Think about the Java ORBClass property. There could actually be two implementations of org.omg.CORBA.ORB present in your scenario. What if the application assumed that the ORB in ref (init'ed by JNDI) were the same type that it init'ed and wanted to cast to that implementation to get some proprietary feature? Boom. ClassCastException. - If we were on the server side and had two ORBs we'd have 2 POA namespaces. I'm sure we could find problems with that. - I'm sure I could come up with other problems. I have to think about your dilemma some more in order to come up with a resonable solution. I just don't think making the slots global is reasonable. Besides, how can they be in Java? If you have multiple class loaders you can't have anything global. If you THINK you only have one ORB instance, ENSURE that you only have one ORB instance. How about this as a solution to your simple case from below? Foo ref = JNDI.lookup(...); // fake syntax of course ORB orbX = ((org.omg.CORBA.portable.ObjectImpl)ref)._get_delegate ().orb (ref); someService = orbX.resolve_initial_reference("someService"); //narrow etc. someService.begin(); ref.bar(...); someService.end(); Russell Butek butek@us.ibm.com Harold Carr on 05/16/2000 01:43:35 PM To: Polar Humenn cc: Harold Carr , interceptors-ftf@omg.org Subject: Re: ORB-scoped slots ids Polar, There is only one thread in my example. There is no need to communicate between interceptors or refs or whatever. There just needs to be agreement on slot ids. Let me reduce my example as far as possible: ORB orbX = ORB.init(...); Foo ref = JNDI.lookup(...); // fake syntax of course someService = orbX.resolve_initial_reference("someService"); // narrow etc. someService.begin(); ref.bar(...); someService.end(); A user would reasonable expect that the service would indeed service ref.bar(). However, since "ref" was obtained from a naming facade which internally instantiates its own orb, the slot id for the service could be different in that orb. Therefore ref.bar() would be left out of the service. The above is very reasonable existing code. The only global thing I am suggesting is slot_ids themselves - a string - just like URLs are global (by convention). Harold X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 16 May 2000 15:39:34 -0400 (EDT) From: Polar Humenn To: Harold Carr cc: Harold Carr , interceptors-ftf@omg.org Subject: Re: ORB-scoped slots ids In-Reply-To: <392196D7.20C22B29@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: o[Td9=Bgd9e+E!!L~>!! "Global" doesn't work. Process Ids are said to be global (in the scope of a process), but they are managed by something greater than a process, namely the operating system. Who manages that slot id in your case? If we sit above ORBs in our programming model and look at ORBs as object instances of scope. We can liken this to operating systems managing processes. When one requests information from the other it is mitigated by the operating system in a constrained way by *well defined interfaces*, either by pipes, file system, shared memory, semaphores, etc. The same paradigm should be held between using two ORBs in the fashion you represent. I.e. the program becomes the mitigator of information passed through well defined interfaces. ORB orbX = ORB.init(....); Foo ref = JNDI.lookup(...); // With its own orb instance. SomeService service = orbX.resolve_initial_references(...); Foo ref1 = orb.string_to_object( JNDI.orb.object_to_string(ref)); // this is akin to mesage passing between ORBs. service.begin(); ref1.bar(); service.end(); Then the right thing happens with respect to the "service". I think I get you now. Correct me if I'm wrong. I am assuming the "service" registers the current slot id in the begin() call for use with the ref1.bar() interception, which would be on the same slot id. And the end() call unregisters it for cleanup or some such matter. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Tue, 16 May 2000 17:30:51 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr CC: Polar Humenn , Harold Carr , interceptors-ftf@omg.org Subject: Re: ORB-scoped slots ids References: <3921B389.D8E03894@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: g*@e9#, > COmments below > > Polar Humenn wrote: > > > > "Global" doesn't work. > > > > Process Ids are said to be global (in the scope of a process), but they > > are managed by something greater than a process, namely the operating > > system. > > > > Who manages that slot id in your case? > > By global I mean managed by the application. I suggested > the following operations: > > void set_slot(String name, Any value); > > Any get_slot(String name) raise (InvalidSlot); > > Then the ids are "global" by convention - just like DNS > or the way we specify ORBInitializers in the java mapping. > > // ... > > > ORB orbX = ORB.init(....); > > Foo ref = JNDI.lookup(...); // With its own orb instance. > > SomeService service = orbX.resolve_initial_references(...); > > > > Foo ref1 = orb.string_to_object( JNDI.orb.object_to_string(ref)); > > // this is akin to mesage passing between ORBs. > > > > service.begin(); > > ref1.bar(); > > service.end(); > > That is an interesting workaround. But I am still trying > to avoid forcing the application (and all its libraries) > to know where all its references come from. > > > > > Then the right thing happens with respect to the "service". > > > > I think I get you now. Correct me if I'm wrong. I am assuming the > > "service" registers the current slot id in the begin() call for use with > > the ref1.bar() interception, which would be on the same slot id. And the > > end() call unregisters it for cleanup or some such matter. > > OK, corrections follows. When an ORBInitializer for the service runs > it allocates a slot id. It would pass that id to all the interceptors > its creates and registers. It would also remember the id in a service > object that it would register with intial references. > > All "begin" does is put information in the slot indexed by the id. > "end" may remove stuff from the slot, but it is somewhat irrelevant > to the problem I raising. > > H > > > > > Cheers, > > -Polar > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com Date: Tue, 16 May 2000 13:46:01 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Harold Carr , interceptors-ftf@omg.org Subject: Re: ORB-scoped slots ids References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: /S&!!V"Rd9T)1e90[:e9 COmments below Polar Humenn wrote: > > "Global" doesn't work. > > Process Ids are said to be global (in the scope of a process), but they > are managed by something greater than a process, namely the operating > system. > > Who manages that slot id in your case? By global I mean managed by the application. I suggested the following operations: void set_slot(String name, Any value); Any get_slot(String name) raise (InvalidSlot); Then the ids are "global" by convention - just like DNS or the way we specify ORBInitializers in the java mapping. // ... > ORB orbX = ORB.init(....); > Foo ref = JNDI.lookup(...); // With its own orb instance. > SomeService service = orbX.resolve_initial_references(...); > > Foo ref1 = orb.string_to_object( JNDI.orb.object_to_string(ref)); > // this is akin to mesage passing between ORBs. > > service.begin(); > ref1.bar(); > service.end(); That is an interesting workaround. But I am still trying to avoid forcing the application (and all its libraries) to know where all its references come from. > > Then the right thing happens with respect to the "service". > > I think I get you now. Correct me if I'm wrong. I am assuming the > "service" registers the current slot id in the begin() call for use > with > the ref1.bar() interception, which would be on the same slot id. And > the > end() call unregisters it for cleanup or some such matter. OK, corrections follows. When an ORBInitializer for the service runs it allocates a slot id. It would pass that id to all the interceptors its creates and registers. It would also remember the id in a service object that it would register with intial references. All "begin" does is put information in the slot indexed by the id. "end" may remove stuff from the slot, but it is somewhat irrelevant to the problem I raising. H > > Cheers, > -Polar > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com Date: Tue, 16 May 2000 13:53:40 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: butek@us.ibm.com CC: interceptors-ftf@omg.org Subject: Re: ORB-scoped slots ids References: <852568E1.006AB399.00@d54mta04.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: "!1e9gi`!!a7>!! > This is bigger than just slots and interceptors. We just happen to see it > with slots. The problem with this scenario is that there is an ORB that > the application doesn't know about (or if you prefer, an ORB that JNDI > doesn't know about). That can be dangerous. > > - Think about the Java ORBClass property. There could actually be two > implementations of org.omg.CORBA.ORB present in your scenario. What if the > application assumed that the ORB in ref (init'ed by JNDI) were the same > type that it init'ed and wanted to cast to that implementation to get some > proprietary feature? Boom. ClassCastException. I do not think we (i.e., OMG) should be concerned with non-standard features so the cast to an implementation type to get a properietary feature is not a concern. > - If we were on the server side and had two ORBs we'd have 2 POA > namespaces. I'm sure we could find problems with that. > - I'm sure I could come up with other problems. > > I have to think about your dilemma some more in order to come up with a > resonable solution. I just don't think making the slots global is > reasonable. Besides, how can they be in Java? If you have multiple class > loaders you can't have anything global. I proposed the following solution: void set_slot(String name, Any value); Any get_slot(String name) raise (InvalidSlot); These could either replace the existing set/get_slot (and also then remove allocate_slot_id) or could be added to the existing API. Then the strings are "global" in manner similar to the way the java mapping specifies ORBInitializers - my convention - probably reverse dns ... > > If you THINK you only have one ORB instance, ENSURE that you only > have one > ORB instance. How about this as a solution to your simple case from > below? > > Foo ref = JNDI.lookup(...); // fake syntax of course > ORB orbX = > ((org.omg.CORBA.portable.ObjectImpl)ref)._get_delegate > ().orb (ref); > someService = orbX.resolve_initial_reference("someService"); > //narrow > etc. > someService.begin(); > ref.bar(...); > someService.end(); > > Russell Butek > butek@us.ibm.com That workaround is relates to Polar's workaround. However, it means that the programmer has to know where they get all their references from so they can force them into the right orb at the right moment' in the context of a service. Not a very friendly API. Harold Date: Thu, 18 May 2000 12:35:33 -0700 (PDT) Message-Id: <200005181935.MAA21855@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org Subject: Re: ORB-scoped slot ids Content-Type: text X-UIDL: \UX!!,3He9DFG!!KXDe9 The initial responses seemed to assume that one has complete control all orb instantiations and knowledge of where all references were obtained. The following code shows a case where one does not control all orb instantiations: ORB orbX = ORB.init(...); Foo ref = JNDI.lookup(...); // creates and uses its own ORB someService = orbX.resolve_initial_reference("someService"); // narrow etc. someService.begin(); ref.bar(...); someService.end(); The workarounds then suggested were to somehow get the ref into the same ORB scope as the service. Something like: serviceOrb = someService.getOrb(); serviceRef = serviceOrb.string_to_object(orbX.object_to_string(ref)) someService.begin(); serviceRef.bar(...); someService.end(); This workaround does not scale. If there are thousands of object references involved in the service scope then getting them into the "proper" orb scope would impact performance. It also does not always work. Consider: someService.begin(); someOtherProcedure(...); someService.end(); All calls made in someOtherProcedure and any of its subcalls would need to know the serviceOrb so they could then make substitute refs in the right scope. This seems to be poor software engineering and impossible if owns does not own all the code. A simple solution is to have set_slot and get_slot use strings as ids: void set_slot(String name, Any value); Any get_slot(String name) raise (InvalidSlot); The strings would be unique by convention (just like DNS and the way the PI Java mapping specifies ORBInitializer). Then someService.begin() would set its slot via: set_slot("someServiceSlot", ...); Regardless of the ORB, the slot table associated with the current thread would would get the value. When ref.bar() is invoked, the slot table of the current thread is logically copied and made available via ClientRequentInfo. This happens in the scope of the orb associated with ref. When the interceptors run they will access the slot via: info.get_slot("someServiceSlot"); This will get the "copy" of the current threads slot table at that position, which is correct. By making the slot table indexed by strings, there is no possibility (other than breaking convention) of having different slots ids in different orb scopes (as is the case with the current spec). If we assume there is a second invocation: ref2.bar(...); inside the service boundary of the original example above it works fine also, regardless of the orb associated with ref2. In other words, the services and all invocation on references do not need to agree on orbs. Harold Date: Thu, 18 May 2000 17:49:10 -0230 From: Matthew Newhook To: Harold Carr , h@ooc.com Cc: interceptors-ftf@omg.org Subject: Re: ORB-scoped slot ids Message-ID: <20000518174910.A15905@ooc.com> References: <200005181935.MAA21855@shorter.eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <200005181935.MAA21855@shorter.eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: JA'!!oZ?e9EjMe9*!Ke9 Hi Harold, On Thu, May 18, 2000 at 12:35:33PM -0700, Harold Carr wrote: >[..] > A simple solution is to have set_slot and get_slot use strings as > ids: > > void set_slot(String name, Any value); > Any get_slot(String name) raise (InvalidSlot); > > The strings would be unique by convention (just like DNS and the > way the PI Java mapping specifies ORBInitializer). Here are a few more reasons why I think this is a poor idea: - This breaks current implementations of the PI spec. - This forces global data to be present. Currently, AFAIK, the only global data that is mandated in the spec (and even the existence of this is not totally clear) is the presence of a set of ORBs. In addition I'll point out that Java lacks this. - Forces me to either have global services (which I do not want) OR invent unique names for the slots. 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, 18 May 2000 13:30:22 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Harold Carr , h@ooc.com, interceptors-ftf@omg.org Subject: Re: ORB-scoped slot ids References: <200005181935.MAA21855@shorter.eng.sun.com> <20000518174910.A15905@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 5Rf!!iiJe9X;Je9*$2e9 Comments below: Matthew Newhook wrote: > Here are a few more reasons why I think this is a poor idea: > ... Do you have an alternate solution? H From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA36442 for ; Thu, 18 May 2000 16:29:11 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id QAA33556 for ; Thu, 18 May 2000 16:49:13 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E3.00725DAA ; Thu, 18 May 2000 16:49:10 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568E3.00725ACF.00@d54mta04.raleigh.ibm.com> Date: Thu, 18 May 2000 16:49:00 -0400 Subject: Re: ORB-scoped slot ids Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: [YW!!)IA!!j4*!!AAF!! Another problem with Strings in the slot interfaces is performance. With longs we could simply index into an array. With strings we have to have a hashtable. Remember that we want interceptors to be as performant as possible. Sorry, Harold, I don't like this but I don't have a solution for you, yet; though I'll stress again the fact that this isn't just a slot issue. It's an issue with how OMG views ORBs, and therefore it goes beyond interceptors. I suspect most folks have assumed that there is only one ORB, so this issue has been sidestepped until now. Russell Butek butek@us.ibm.com Matthew Newhook on 05/18/2000 12:49:10 PM To: Harold Carr , h@ooc.com cc: interceptors-ftf@omg.org Subject: Re: ORB-scoped slot ids Hi Harold, On Thu, May 18, 2000 at 12:35:33PM -0700, Harold Carr wrote: >[..] > A simple solution is to have set_slot and get_slot use strings as > ids: > > void set_slot(String name, Any value); > Any get_slot(String name) raise (InvalidSlot); > > The strings would be unique by convention (just like DNS and the > way the PI Java mapping specifies ORBInitializer). Here are a few more reasons why I think this is a poor idea: - This breaks current implementations of the PI spec. - This forces global data to be present. Currently, AFAIK, the only global data that is mandated in the spec (and even the existence of this is not totally clear) is the presence of a set of ORBs. In addition I'll point out that Java lacks this. - Forces me to either have global services (which I do not want) OR invent unique names for the slots. 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, 18 May 2000 18:54:24 -0230 From: Matthew Newhook To: Harold Carr Cc: Harold Carr , h@ooc.com, interceptors-ftf@omg.org Subject: Re: ORB-scoped slot ids Message-ID: <20000518185424.A16961@ooc.com> References: <200005181935.MAA21855@shorter.eng.sun.com> <20000518174910.A15905@ooc.com> <392452DE.B4B2E997@sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <392452DE.B4B2E997@sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: ,@ld91:\d9$,#e9JY0e9 Hi, On Thu, May 18, 2000 at 01:30:22PM -0700, Harold Carr wrote: > Comments below: > > Matthew Newhook wrote: > > > Here are a few more reasons why I think this is a poor idea: > > ... > > Do you have an alternate solution? No. I'm not saying this with malice but I'm sorry to say that I don't want to put any energy into thinking about it because I think that this is simply wrong. > H 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, 18 May 2000 14:30:41 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Harold Carr , h@ooc.com, interceptors-ftf@omg.org Subject: Re: ORB-scoped slot ids References: <200005181935.MAA21855@shorter.eng.sun.com> <20000518174910.A15905@ooc.com> <392452DE.B4B2E997@sun.com> <20000518185424.A16961@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ^Y No. I'm not saying this with malice but I'm sorry to say that I don't > want to put any energy into thinking about it because I think that this > is simply wrong. > What is wrong - the solution? Or are you saying that what I presented is not a problem? H Date: Thu, 18 May 2000 15:08:17 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: butek@us.ibm.com CC: interceptors-ftf@omg.org Subject: Re: ORB-scoped slot ids References: <852568E3.00725ACF.00@d54mta04.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: T]Rd9#A=e9J-%e9Cjjd9 Comments below: butek@us.ibm.com wrote: > > Another problem with Strings in the slot interfaces is performance. With > longs we could simply index into an array. With strings we have to have a > hashtable. Remember that we want interceptors to be as performant as > possible. I would implement this as a linear list that converts dynamically to a hashtable once the list reaches a certain size. I would expect that the number of slots would generally only be as large as 10 - so a linear search in a 10 element list should not be a performance factor. > > Sorry, Harold, I don't like this but I don't have a solution for > you, yet; > though I'll stress again the fact that this isn't just a slot > issue. It's > an issue with how OMG views ORBs, and therefore it goes beyond > interceptors. I suspect most folks have assumed that there is only > one > ORB, so this issue has been sidestepped until now. Yes, I agree that it is a larger issue. But in terms of PI it is an issue with PICurrent. In the larger case we, OMG, would have to decide that either services are orb-scoped or global. If orb-scoped is the answer then I think the programming model becomes very complex - i.e., the need to ensure that all your references are scoped in the same orb as your service. And what if there are more than one service at the same time: service1.begin() service2.begin() ref1.foo() ref2.bar() ... Certaily a global view makes this easier to deal with. If people agree with a global view of services then we need to solve the PICurrent slot problem. I gave a proposal for that (which Ken Cavanaugh just showed me doesn't work either. I'll leave the explaination for later if anyone is interested). So, 1. should services be global or orb-scoped? 2. if orb-scoped then how does one deal with the situation shown in the code above when each service and ref is associated with a different orb? 3. if global-scoped how do we solve the slot id problem? Java forces us to think about this because it is easy to have multiple orbs, even multiple orbs with different classloaders and implementation class names. Cheers, Harold From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: ORB-scoped slot ids Date: Thu, 18 May 2000 18:52:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: GbNe9"+2e9"O5e9bILe9 Lets see - index by integer is 1 or 2 instructions (maybe 3 or 4 with bounds checking). Searching a list of strings, best case, is half a dozen instructions plus some number times the total number of characters in the strings. Multiply this times the number of interceptors installed and the number of different interception points. And in java I believe strings are protected by mutexes, so you flog the mutex of each string each time you compare it. For the Python mapping, fine; for the Java mapping, your call; for the C++ mapping, no way. Paul > -----Original Message----- > From: Harold Carr [mailto:harold.carr@sun.com] > Sent: Thursday, May 18, 2000 6:08 PM > To: butek@us.ibm.com > Cc: interceptors-ftf@omg.org > Subject: Re: ORB-scoped slot ids > > > Comments below: > > butek@us.ibm.com wrote: > > > > Another problem with Strings in the slot interfaces is > performance. With > > longs we could simply index into an array. With strings we > have to have a > > hashtable. Remember that we want interceptors to be as > performant as > > possible. > > I would implement this as a linear list that converts dynamically to a > hashtable once the list reaches a certain size. I would > expect that the > number of slots would generally only be as large as 10 - so a linear > search in a 10 element list should not be a performance factor. Date: Thu, 18 May 2000 16:08:23 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interceptors-ftf@omg.org Subject: Re: ORB-scoped slot ids References: <9B164B713EE9D211B6DC0090273CEEA926BEA2@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 0j(!!J&+e97?4!!,_U!! Thanks Paul, But what I am really more interested in is the larger problem. Any thoughts on it? H Paul Kyzivat wrote: > > Lets see - index by integer is 1 or 2 instructions (maybe 3 or 4 with bounds > checking). Searching a list of strings, best case, is half a dozen > instructions plus some number times the total number of characters in the > strings. > > Multiply this times the number of interceptors installed and the number of > different interception points. > > And in java I believe strings are protected by mutexes, so you flog the > mutex of each string each time you compare it. > > For the Python mapping, fine; for the Java mapping, your call; for the C++ > mapping, no way. > > Paul > > > -----Original Message----- > > From: Harold Carr [mailto:harold.carr@sun.com] > > Sent: Thursday, May 18, 2000 6:08 PM > > To: butek@us.ibm.com > > Cc: interceptors-ftf@omg.org > > Subject: Re: ORB-scoped slot ids > > > > > > Comments below: > > > > butek@us.ibm.com wrote: > > > > > > Another problem with Strings in the slot interfaces is > > performance. With > > > longs we could simply index into an array. With strings we > > have to have a > > > hashtable. Remember that we want interceptors to be as > > performant as > > > possible. > > > > I would implement this as a linear list that converts dynamically to a > > hashtable once the list reaches a certain size. I would > > expect that the > > number of slots would generally only be as large as 10 - so a linear > > search in a 10 element list should not be a performance factor. Date: Thu, 18 May 2000 16:08:23 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interceptors-ftf@omg.org Subject: Re: ORB-scoped slot ids References: <9B164B713EE9D211B6DC0090273CEEA926BEA2@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 0j(!!J&+e97?4!!,_U!! Thanks Paul, But what I am really more interested in is the larger problem. Any thoughts on it? H Paul Kyzivat wrote: > > Lets see - index by integer is 1 or 2 instructions (maybe 3 or 4 with bounds > checking). Searching a list of strings, best case, is half a dozen > instructions plus some number times the total number of characters in the > strings. > > Multiply this times the number of interceptors installed and the number of > different interception points. > > And in java I believe strings are protected by mutexes, so you flog the > mutex of each string each time you compare it. > > For the Python mapping, fine; for the Java mapping, your call; for the C++ > mapping, no way. > > Paul > > > -----Original Message----- > > From: Harold Carr [mailto:harold.carr@sun.com] > > Sent: Thursday, May 18, 2000 6:08 PM > > To: butek@us.ibm.com > > Cc: interceptors-ftf@omg.org > > Subject: Re: ORB-scoped slot ids > > > > > > Comments below: > > > > butek@us.ibm.com wrote: > > > > > > Another problem with Strings in the slot interfaces is > > performance. With > > > longs we could simply index into an array. With strings we > > have to have a > > > hashtable. Remember that we want interceptors to be as > > performant as > > > possible. > > > > I would implement this as a linear list that converts dynamically to a > > hashtable once the list reaches a certain size. I would > > expect that the > > number of slots would generally only be as large as 10 - so a linear > > search in a 10 element list should not be a performance factor. Date: Thu, 18 May 2000 20:57:36 -0230 From: Matthew Newhook To: Harold Carr Cc: interceptors-ftf@omg.org Subject: Re: ORB-scoped slot ids Message-ID: <20000518205736.B18638@ooc.com> References: <200005181935.MAA21855@shorter.eng.sun.com> <20000518174910.A15905@ooc.com> <392452DE.B4B2E997@sun.com> <20000518185424.A16961@ooc.com> <39246101.A49E490C@sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <39246101.A49E490C@sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: %^U!!H9A!!R,+!!:\X!! Hi, On Thu, May 18, 2000 at 02:30:41PM -0700, Harold Carr wrote: > > > Matthew Newhook wrote: > > > No. I'm not saying this with malice but I'm sorry to say that I don't > > want to put any energy into thinking about it because I think that this > > is simply wrong. > > > > What is wrong - the solution? Or are you saying that what > I presented is not a problem? IMHO, what you presented as a problem is not a problem. It's simply the way that CORBA works. Object references and services are bound to ORBs and are not global in any way. Probably the easiest way that the problem you presented should be solved is to ask the JNDI object to create the reference on a particular ORB. > H 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, 18 May 2000 16:49:39 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: interceptors-ftf@omg.org Subject: Re: ORB-scoped slot ids References: <200005181935.MAA21855@shorter.eng.sun.com> <20000518174910.A15905@ooc.com> <392452DE.B4B2E997@sun.com> <20000518185424.A16961@ooc.com> <39246101.A49E490C@sun.com> <20000518205736.B18638@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: @_?!!M\(e9213!!+1H!! > you presented should be solved is to ask the JNDI object to create the > reference on a particular ORB. Technically easy but the JNDI API already exists without it... Also, there are probably other ways to end up with object refs with a different orb than the service so it still seems like a hassle to use services. H Date: Thu, 18 May 2000 21:23:25 -0230 From: Matthew Newhook To: Harold Carr Cc: interceptors-ftf@omg.org Subject: Re: ORB-scoped slot ids Message-ID: <20000518212325.A19095@ooc.com> References: <200005181935.MAA21855@shorter.eng.sun.com> <20000518174910.A15905@ooc.com> <392452DE.B4B2E997@sun.com> <20000518185424.A16961@ooc.com> <39246101.A49E490C@sun.com> <20000518205736.B18638@ooc.com> <39248193.1B9C310@sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <39248193.1B9C310@sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: B"j!!\0kd9&ej!!n(9!! Hi, On Thu, May 18, 2000 at 04:49:39PM -0700, Harold Carr wrote: > > > you presented should be solved is to ask the JNDI object to create the > > reference on a particular ORB. > > Technically easy but the JNDI API already exists without it... Sorry, but then IMO the JNDI API must be fixed not CORBA. > Also, there are probably other ways to end up with object refs > with a different orb than the service so it still seems > like a hassle to use services. I agree that it's possible to create a broken API that returns an object-reference without any idea of the ORB to which it belongs. Of course, it's possible that I have a very restricted view of the world ;) > H 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 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 18 May 2000 20:22:04 -0400 (EDT) From: Polar Humenn To: Matthew Newhook cc: Harold Carr , interceptors-ftf@omg.org Subject: Re: ORB-scoped slot ids In-Reply-To: <20000518212325.A19095@ooc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: VD$e9)BXd9~L)!!9=#!! On Thu, 18 May 2000, Matthew Newhook wrote: > Hi, > > On Thu, May 18, 2000 at 04:49:39PM -0700, Harold Carr wrote: > > > > > you presented should be solved is to ask the JNDI object to > create the > > > reference on a particular ORB. > > > > Technically easy but the JNDI API already exists without it... > > Sorry, but then IMO the JNDI API must be fixed not CORBA. Oh why?? We are currently jumping through Hoops and rings in CSIv2 because everybody is so flipping hooked on using SSL, which is terribly insufficient for security in CORBA. We have to do this instead of something correct, like SECIOP. all in the name of EJB! CORBA security will take a dive. Don't expect the correct and right thing to happen. We don't seem to win arguments on the "correct" position, only the popular one. Which is more popular Java or CORBA. Go figure. Cheers, -Polar > > Also, there are probably other ways to end up with object refs > > with a different orb than the service so it still seems > > like a hassle to use services. > I agree that it's possible to create a broken API that returns an > object-reference without any idea of the ORB to which it belongs. Of > course, it's possible that I have a very restricted view of the > world ;) > > > H > > 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 > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: "Peter Walker" To: "Matthew Newhook" , "Harold Carr" Cc: Subject: RE: ORB-scoped slot ids Date: Thu, 18 May 2000 17:30:26 -0700 Message-ID: <001001bfc129$6d864840$88fb9081@pacific.eng.sun.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20000518205736.B18638@ooc.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: _3$e9gb2!!-dZ!!HE=!! > > IMHO, what you presented as a problem is not a problem. It's simply > the > way that CORBA works. Object references and services are bound to > ORBs > and are not global in any way. Probably the easiest way that the > problem > you presented should be solved is to ask the JNDI object to create > the > reference on a particular ORB. > Ah I love that sound - "thats the way it works" - can you say SOAP ? Pj. Date: Fri, 19 May 2000 10:57:06 +1000 (EST) From: Michi Henning To: Peter Walker cc: Matthew Newhook , Harold Carr , interceptors-ftf@omg.org Subject: RE: ORB-scoped slot ids In-Reply-To: <001001bfc129$6d864840$88fb9081@pacific.eng.sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: jm8e9&*(e9/7#e9k5h!! On Thu, 18 May 2000, Peter Walker wrote: > Ah I love that sound - "thats the way it works" - can you say SOAP ? What's wrong with that? Didn't you know -- SOAP is the best thing since WATER :-) Michi. Date: Fri, 19 May 2000 10:54:22 +1000 (EST) From: Michi Henning To: Matthew Newhook cc: Harold Carr , interceptors-ftf@omg.org Subject: Re: ORB-scoped slot ids In-Reply-To: <20000518205736.B18638@ooc.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: :bKe9'fNe9K#~!!n)Ie9 On Thu, 18 May 2000, Matthew Newhook wrote: > > What is wrong - the solution? Or are you saying that what > > I presented is not a problem? > > IMHO, what you presented as a problem is not a problem. It's simply > > the > way that CORBA works. Object references and services are bound to > > ORBs > and are not global in any way. Probably the easiest way that the > > problem > you presented should be solved is to ask the JNDI object to create > > the > reference on a particular ORB. I agree with that. In addition, with the QoS framework, we have QoS parameters attached to various scopes. I don't believe we can have the notion of a "global" scope at all, given that this would leave no place to hang any QoS parameters. Cheers, Michi. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 18 May 2000 20:15:43 -0400 (EDT) From: Polar Humenn To: Harold Carr cc: Matthew Newhook , interceptors-ftf@omg.org Subject: Re: ORB-scoped slot ids In-Reply-To: <39248193.1B9C310@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: hN1!!l)F!!:O)!!cLo!! On Thu, 18 May 2000, Harold Carr wrote: > > > you presented should be solved is to ask the JNDI object to create the > > reference on a particular ORB. > > Technically easy but the JNDI API already exists without it... Java, Java, EJB, and Java! I can only say "that's too bad" for that problem. Java can change it "standards" just as easily as CORBA, probably more so. > Also, there are probably other ways to end up with object refs > with a different orb than the service so it still seems > like a hassle to use services. I don't see why two orbs have to interact with each other, other through the well defined interfaces on the ORB or obviously using GIOP. Is there a reason, other than some Java interface doesn't support it, to have two different orbs in a programming paradigm? I don't like Global. Global is an undefined "scope". If there is a reason two orbs really need to interact with each other or share some information, we should come up with a greater scheme (abstraction) that encompasses collections of collaborating ORB instances. I can see in my cystal ball: sooner or later someone will want two of those! Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 18 May 2000 21:15:22 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Harold Carr , interceptors-ftf@omg.org Subject: Re: ORB-scoped slot ids References: <200005181935.MAA21855@shorter.eng.sun.com> <20000518174910.A15905@ooc.com> <392452DE.B4B2E997@sun.com> <20000518185424.A16961@ooc.com> <39246101.A49E490C@sun.com> <20000518205736.B18638@ooc.com> <39248193.1B9C310@sun.com> <20000518212325.A19095@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: H(8!!5SVd9oBn!!O-@e9 First, I'm solidly in the camp that slot ids should be ORB-scoped, and not globally scoped. Manipulating one ORB's Current of some type should not effect any other ORBs. Matthew Newhook wrote: > > Hi, > > On Thu, May 18, 2000 at 04:49:39PM -0700, Harold Carr wrote: > > > > > you presented should be solved is to ask the JNDI object to create the > > > reference on a particular ORB. > > > > Technically easy but the JNDI API already exists without it... > > Sorry, but then IMO the JNDI API must be fixed not CORBA. My guess is that changing the JNDI API is unlikely, but I could be wrong. I think this problem is partly a result of the decision in the Java mapping to deviate from the CORBA core by having its ORB_init return different ORBs even when called with the same ORB ID. This makes it difficult to specify a way for the application to get its hands on the same ORB that is being used underneath JNDI. This decision in the Java mapping may also be responsible for it being apparently more common in Java for an application to use multiple ORBs than it is in C++. In C++, the programmer has to intentionally come up with distinct ORB IDs if it wants multiple ORB instances. > > > Also, there are probably other ways to end up with object refs > > with a different orb than the service so it still seems > > like a hassle to use services. > > I agree that it's possible to create a broken API that returns an > object-reference without any idea of the ORB to which it belongs. Of > course, it's possible that I have a very restricted view of the world ;) I think the world you are viewing was intentionally limited! I don't think its ever really safe to use an ORB that you don't control, or at least have some idea how it is configured, etc. For example, what if a JNDI implementation were to set some bizzare policy at ORB level, such as a really short timeout or something? An application trying to use this ORB would wind up with lots of timeouts occuring unless it bothered to override the timeout policies at the thread or object levels. If the application changed the timeout policy at the ORB level, it might somehow break the JNDI provider implementation. I really don't think CORBA has been designed/evolved with the intent of fullly supporting the use of "anonymous" ORBs where the application doesn't control the ORB level policies. I see several ways forward: 1) See if the Java mapping of ORB_init can be fixed to conform to the core specification, so that applications and JNDI provider implementations could coordinate on what ORB is being used when desired (maybe the "default" ORB by default). 2) Provide a new CORBA::Object::_get_orb() pseudo operation so that applications would use if they need access to the ORB instance to which a reference returned from JNDI belongs. They might have to be prepared for different objects returned from JNDI to belong to different ORBs, though, since a JNDI provider might call ORB_init each time its called, or there might be some sort of federation between different JNDI CORBA naming provider implementations (if JNDI makes this possible). 3) Require applications that obtain references belonging to "anonymous" ORBs to call object_to_string on the "anonymous" ORB's object reference and then pass the result to string_to_object on the ORB they want to use, if they care. I don't think making Currents from different ORBs manipulate the same state is a valid solution. -Bob > > > H > > 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: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: ORB-scoped slot ids Date: Fri, 19 May 2000 08:22:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: U,He9Q5W!!5Rg!!L -----Original Message----- > From: Bob Kukura [mailto:kukura@iona.com] > Sent: Thursday, May 18, 2000 9:15 PM > To: Matthew Newhook > Cc: Harold Carr; interceptors-ftf@omg.org > Subject: Re: ORB-scoped slot ids > > > First, I'm solidly in the camp that slot ids should be ORB-scoped, and > not globally scoped. Manipulating one ORB's Current of some > type should > not effect any other ORBs. > > Matthew Newhook wrote: > > > > Hi, > > > > On Thu, May 18, 2000 at 04:49:39PM -0700, Harold Carr wrote: > > > > > > > you presented should be solved is to ask the JNDI > object to create the > > > > reference on a particular ORB. > > > > > > Technically easy but the JNDI API already exists without it... > > > > Sorry, but then IMO the JNDI API must be fixed not CORBA. > > My guess is that changing the JNDI API is unlikely, but I could be > wrong. > > I think this problem is partly a result of the decision in the Java > mapping to deviate from the CORBA core by having its ORB_init return > different ORBs even when called with the same ORB ID. This makes it > difficult to specify a way for the application to get its hands on the > same ORB that is being used underneath JNDI. This decision > in the Java > mapping may also be responsible for it being apparently more common in > Java for an application to use multiple ORBs than it is in > C++. In C++, > the programmer has to intentionally come up with distinct ORB > IDs if it > wants multiple ORB instances. > > > > > > Also, there are probably other ways to end up with object refs > > > with a different orb than the service so it still seems > > > like a hassle to use services. > > > > I agree that it's possible to create a broken API that returns an > > object-reference without any idea of the ORB to which it belongs. Of > > course, it's possible that I have a very restricted view of > the world ;) > > I think the world you are viewing was intentionally limited! I don't > think its ever really safe to use an ORB that you don't control, or at > least have some idea how it is configured, etc. For example, > what if a > JNDI implementation were to set some bizzare policy at ORB level, such > as a really short timeout or something? An application trying to use > this ORB would wind up with lots of timeouts occuring unless > it bothered > to override the timeout policies at the thread or object > levels. If the > application changed the timeout policy at the ORB level, it might > somehow break the JNDI provider implementation. I really don't think > CORBA has been designed/evolved with the intent of fullly > supporting the > use of "anonymous" ORBs where the application doesn't control the ORB > level policies. > > I see several ways forward: > > 1) See if the Java mapping of ORB_init can be fixed to conform to the > core specification, so that applications and JNDI provider > implementations could coordinate on what ORB is being used > when desired > (maybe the "default" ORB by default). > > 2) Provide a new CORBA::Object::_get_orb() pseudo operation so that > applications would use if they need access to the ORB > instance to which > a reference returned from JNDI belongs. They might have to > be prepared > for different objects returned from JNDI to belong to different ORBs, > though, since a JNDI provider might call ORB_init each time > its called, > or there might be some sort of federation between different JNDI CORBA > naming provider implementations (if JNDI makes this possible). > > 3) Require applications that obtain references belonging to > "anonymous" > ORBs to call object_to_string on the "anonymous" ORB's object > reference > and then pass the result to string_to_object on the ORB they want to > use, if they care. > > I don't think making Currents from different ORBs manipulate the same > state is a valid solution. > > -Bob > > > > > > H > > > > 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, 19 May 2000 08:45:26 -0700 (PDT) From: Jeff Nisewanger Reply-To: Jeff Nisewanger Subject: RE: ORB-scoped slot ids To: interceptors-ftf@omg.org, paulk@roguewave.com MIME-Version: 1.0 Content-MD5: 0XTzBEeX0o5CKdnM/yW6jg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: "J"e9*3gd9^_Q!!6ZQ!! > And in java I believe strings are protected by mutexes, so you flog the > mutex of each string each time you compare it. > False. Strings are immutable in Java and so no synchronization is required. Likewise, the hashCode() method for a string can be computed once and cached (and is in Java 2). Jeff From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: ORB-scoped slot ids Date: Fri, 19 May 2000 12:50:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: $!c!!;/?!!j@$"!$'_d9 > From: Jeff Nisewanger [mailto:Jeff.Nisewanger@eng.sun.com] > > And in java I believe strings are protected by mutexes, so > you flog the > > mutex of each string each time you compare it. > > > False. Strings are immutable in Java and so no synchronization > is required. Likewise, the hashCode() method for a string can > be computed > once and cached (and is in Java 2). OK, maybe it was StringBuf or something like that with a mutex. And it is nice that string hash can be cached in java. But the C++ language binding for string doesn't leave room for any optimizations. So it is a very poor choice for a key. Paul From: Jeffrey Mischkinsky Message-Id: <200005191700.KAA21653@wheel.dcn.davis.ca.us> Subject: Re: ORB-scoped slot ids To: paulk@roguewave.com (Paul Kyzivat) Date: Fri, 19 May 2000 10:00:20 -0700 (PDT) Cc: interceptors-ftf@omg.org In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BEA3@bos1.noblenet.com> from "Paul Kyzivat" at May 19, 2000 08:22:54 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: :g3e97HQ!!/INe9O4&e9 'Paul Kyzivat' writes: > > Java is currently non-conformant in its implementation of ORBinit. > This was discussed at a working session at the last meeting, and > I believe it was going to be formally raised as an issue. > Once this is fixed, there should be more options for addressing > these other problems in java. As I recall, the reason for Java's behavior has to do with the Java security model in browsers. If one didn't get a "new" orb, then applets running in the same browser could get access to each others supposedly private data. This was deemed to be important enough to change the model from that of C++'s. I suspect "non-conformant" is too strong. Non-conformant with what? The way things are done in a different language with a different programming model, and different requirements? It truly is the case that different environments do have different constraints. jeff > > Paul > > > -----Original Message----- > > From: Bob Kukura [mailto:kukura@iona.com] > > Sent: Thursday, May 18, 2000 9:15 PM > > To: Matthew Newhook > > Cc: Harold Carr; interceptors-ftf@omg.org > > Subject: Re: ORB-scoped slot ids > > > > > > First, I'm solidly in the camp that slot ids should be ORB-scoped, >and > > not globally scoped. Manipulating one ORB's Current of some > > type should > > not effect any other ORBs. > > > > Matthew Newhook wrote: > > > > > > Hi, > > > > > > On Thu, May 18, 2000 at 04:49:39PM -0700, Harold Carr wrote: > > > > > > > > > you presented should be solved is to ask the JNDI > > object to create the > > > > > reference on a particular ORB. > > > > > > > > Technically easy but the JNDI API already exists without it... > > > > > > Sorry, but then IMO the JNDI API must be fixed not CORBA. > > > > My guess is that changing the JNDI API is unlikely, but I could be > > wrong. > > > > I think this problem is partly a result of the decision in the >Java > > mapping to deviate from the CORBA core by having its ORB_init >return > > different ORBs even when called with the same ORB ID. This makes >it > > difficult to specify a way for the application to get its hands on >the > > same ORB that is being used underneath JNDI. This decision > > in the Java > > mapping may also be responsible for it being apparently more >common in > > Java for an application to use multiple ORBs than it is in > > C++. In C++, > > the programmer has to intentionally come up with distinct ORB > > IDs if it > > wants multiple ORB instances. > > > > > > > > > Also, there are probably other ways to end up with object refs > > > > with a different orb than the service so it still seems > > > > like a hassle to use services. > > > > > > I agree that it's possible to create a broken API that returns >an > > > object-reference without any idea of the ORB to which it >belongs. Of > > > course, it's possible that I have a very restricted view of > > the world ;) > > > > I think the world you are viewing was intentionally limited! I >don't > > think its ever really safe to use an ORB that you don't control, >or at > > least have some idea how it is configured, etc. For example, > > what if a > > JNDI implementation were to set some bizzare policy at ORB level, >such > > as a really short timeout or something? An application trying to >use > > this ORB would wind up with lots of timeouts occuring unless > > it bothered > > to override the timeout policies at the thread or object > > levels. If the > > application changed the timeout policy at the ORB level, it might > > somehow break the JNDI provider implementation. I really don't >think > > CORBA has been designed/evolved with the intent of fullly > > supporting the > > use of "anonymous" ORBs where the application doesn't control the >ORB > > level policies. > > > > I see several ways forward: > > > > 1) See if the Java mapping of ORB_init can be fixed to conform to >the > > core specification, so that applications and JNDI provider > > implementations could coordinate on what ORB is being used > > when desired > > (maybe the "default" ORB by default). > > > > 2) Provide a new CORBA::Object::_get_orb() pseudo operation so >that > > applications would use if they need access to the ORB > > instance to which > > a reference returned from JNDI belongs. They might have to > > be prepared > > for different objects returned from JNDI to belong to different >ORBs, > > though, since a JNDI provider might call ORB_init each time > > its called, > > or there might be some sort of federation between different JNDI >CORBA > > naming provider implementations (if JNDI makes this possible). > > > > 3) Require applications that obtain references belonging to > > "anonymous" > > ORBs to call object_to_string on the "anonymous" ORB's object > > reference > > and then pass the result to string_to_object on the ORB they want >to > > use, if they care. > > > > I don't think making Currents from different ORBs manipulate the >same > > state is a valid solution. > > > > -Bob > > > > > > > > > H > > > > > > 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 > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 From: Jeffrey Mischkinsky Message-Id: <200005191701.KAA21716@wheel.dcn.davis.ca.us> Subject: Re: ORB-scoped slot ids To: paulk@roguewave.com (Paul Kyzivat) Date: Fri, 19 May 2000 10:01:06 -0700 (PDT) Cc: interceptors-ftf@omg.org In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BEA6@bos1.noblenet.com> from "Paul Kyzivat" at May 19, 2000 12:50:14 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: $2S!!LG#e9N(B!!/'h!! 'Paul Kyzivat' writes: > > > From: Jeff Nisewanger [mailto:Jeff.Nisewanger@eng.sun.com] > > > > And in java I believe strings are protected by mutexes, so > > you flog the > > > mutex of each string each time you compare it. > > > > > False. Strings are immutable in Java and so no synchronization > > is required. Likewise, the hashCode() method for a string can > > be computed > > once and cached (and is in Java 2). > > OK, maybe it was StringBuf or something like that with a mutex. > And it is nice that string hash can be cached in java. > > But the C++ language binding for string doesn't leave room for any > optimizations. So it is a very poor choice for a key. Ah if only C++ wasn't so "non-conformant" :-) jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Fri, 19 May 2000 14:52:54 -0230 From: Matthew Newhook To: Jeffrey Mischkinsky Cc: interceptors-ftf@omg.org Subject: Re: ORB-scoped slot ids Message-ID: <20000519145254.A4467@ooc.com> References: <9B164B713EE9D211B6DC0090273CEEA926BEA3@bos1.noblenet.com> <200005191700.KAA21653@wheel.dcn.davis.ca.us> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <200005191700.KAA21653@wheel.dcn.davis.ca.us> Content-Type: text/plain; charset=us-ascii X-UIDL: &\P!!4Ka!!a]Ae9SJ/!! Hi Jeff, On Fri, May 19, 2000 at 10:00:20AM -0700, Jeffrey Mischkinsky wrote: > 'Paul Kyzivat' writes: > > > > Java is currently non-conformant in its implementation of ORBinit. > > This was discussed at a working session at the last meeting, and > > I believe it was going to be formally raised as an issue. > > Once this is fixed, there should be more options for addressing > > these other problems in java. > > As I recall, the reason for Java's behavior has to do with the Java > security model in browsers. If one didn't get a "new" orb, then > applets running in the same browser could get access to each others > supposedly private data. > > This was deemed to be important enough to change the model from that of > C++'s. I suspect "non-conformant" is too strong. Non-conformant with what? > The way things are done in a different language with a different programming > model, and different requirements? How about the following from 99-07-08: ----- // PIDL module CORBA { typedef string ORBid; typedef sequence arg_list; ORB ORB_init (inout arg_list argv, in ORBid orb_identifier); }; The identifier for the ORB will be a name of type CORBA::ORBid. All ORBid strings other than the empty string are allocated by ORB administrators and are not managed by the OMG. ORBid strings other than the empty string are intended to be used to uniquely identify each ORB used within the same address space in a multi-ORB application. These special ORBid strings are specific to each ORB implementation and the ORB administrator is responsible for ensuring that the names are unambiguous. ----- Isn't it the case that Java is non-conforming to the core since it has no concept of an ORB id? > It truly is the case that different environments do have different constraints. > jeff > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff@persistence.com +1 650-372-3604 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: Jeffrey Mischkinsky Message-Id: <200005191735.KAA24800@wheel.dcn.davis.ca.us> Subject: Re: ORB-scoped slot ids To: matthew@ooc.com (Matthew Newhook) Date: Fri, 19 May 2000 10:34:46 -0700 (PDT) Cc: interceptors-ftf@omg.org In-Reply-To: <20000519145254.A4467@ooc.com> from "Matthew Newhook" at May 19, 2000 02:52:54 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 9E8!!]k^d9lgf!!OSCe9 'Matthew Newhook' writes: > > Hi Jeff, > > On Fri, May 19, 2000 at 10:00:20AM -0700, Jeffrey Mischkinsky wrote: > > 'Paul Kyzivat' writes: > > > > > > Java is currently non-conformant in its implementation of ORBinit. > > > This was discussed at a working session at the last meeting, and > > > I believe it was going to be formally raised as an issue. > > > Once this is fixed, there should be more options for addressing > > > these other problems in java. > > > > As I recall, the reason for Java's behavior has to do with the Java > > security model in browsers. If one didn't get a "new" orb, then > > applets running in the same browser could get access to each others > > supposedly private data. > > > > This was deemed to be important enough to change the model from that of > > C++'s. I suspect "non-conformant" is too strong. Non-conformant with what? > > The way things are done in a different language with a different programming > > model, and different requirements? > > How about the following from 99-07-08: > > ----- > // PIDL > module CORBA { > typedef string ORBid; > typedef sequence arg_list; > ORB ORB_init (inout arg_list argv, in ORBid orb_identifier); > }; > > The identifier for the ORB will be a name of type CORBA::ORBid. All ORBid > strings other than the empty string are allocated by ORB administrators > and are not managed by the OMG. ORBid strings other than the empty string > are intended to be used to uniquely identify each ORB used within the same > address space in a multi-ORB application. These special ORBid strings > are specific to each ORB implementation and the ORB administrator is > responsible for ensuring that the names are unambiguous. > ----- > > Isn't it the case that Java is non-conforming to the core since it > has no concept of an ORB id? No, It's PIDL. i.e. language mapping dependent i.e. there are no general rules WRT to how PIDL is mapped. If you really want to go back into the dim depths of time... At one time, there were (sort of) implicit rules that PIDL should be mapped according to the syntactic rules of the language mapping, but you couldn't be really guaranteed that the object on which you were invoking (e.g. the orb) was really a remotable, righteous, CORBA object. The stated reason for using PIDL at that time, was that it was a convenient shorthand for specifying some orb stuff in a (pseudo) language-independent way, so that users got the benefit of a uniform api. At the same time, there was a requirement on the part of some that they not be required to do interoperable/portable implementations of the "core" of their orb. Part of that design center was that the orb would be part of the OS and hence one could have a blindingly fast implementation (no marshaling, etc.) and wouldn't want to be required to actually implement the orb, for example, as a righteous "slow" corba object. As I recall the c++ mapping put the final stake in that implicit agreement when it decided to make the mapping of some of the PIDL "more natural" to C++ users, instead of blindly following the C example. There are no rules for PIDL, except what you find in the language mapping chapter. That's why some of us have been trying to not phase out PIDL for many years, and replace it with something more uniform. cheers, jeff > > > It truly is the case that different environments do have different constraints. > > jeff > > -- > > Jeff Mischkinsky > > jmischki@dcn.davis.ca.us +1 530-758-9850 > > jeff@persistence.com +1 650-372-3604 > > 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 > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: ORB-scoped slot ids Date: Fri, 19 May 2000 14:19:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: M]1e95?A!!KW!!!D_/!! Jeff, As I recall, we reached the conclusion that the java mapping is indeed non-conformant with the core specification in its treatment (non-treatment) of ORBid. As such it became the responsibility of the IDL-Java RTF to deal with this as a language mapping issue. *If* the RTF cannot solve this as a language binding issue, then they should raise an issue to the core to change the core spec to something that java can be compatible with. Paul > From: Jeffrey Mischkinsky [mailto:jmischki@wheel.dcn.davis.ca.us] > As I recall, the reason for Java's behavior has to do with the Java > security model in browsers. If one didn't get a "new" orb, then > applets running in the same browser could get access to each others > supposedly private data. > > This was deemed to be important enough to change the model > from that of > C++'s. I suspect "non-conformant" is too strong. > Non-conformant with what? > The way things are done in a different language with a > different programming > model, and different requirements? > It truly is the case that different environments do have > different constraints. > jeff