[omniORB] strange asymmetric behavior

Renzo Tomaselli renzo.tomaselli at tecnotp.it
Mon Jul 21 21:56:50 BST 2003

    I never figured out about those effects on using _this(), since I'm used
to call it just once at construction time.
Well, I think your very final suggestion is the definitive key to get such a
(somewhat secondary) obj ref.
Thank you very much. Great list as usual, since many years.


----- Original Message -----
From: <baileyk at schneider.com>
To: "Omniorb list" <omniorb-list at omniorb-support.com>
Sent: Monday, July 21, 2003 8:00 PM
Subject: Re: [omniORB] strange asymmetric behavior

> I didn't expect your production code.  A typical approach to solving a
> problem like this is to write a very small test case.  If you do that (and
> I know it can be a pain sometimes) then you'd likely get your answers from
> this list in short order -- either a verified bug or an explanation for
> behavior.
> I've seen plenty of advice against using _this() at all.  It is easy to
> activate a new object in the root POA, incarnated by the servant, without
> meaning to.  Just ask yourself how a servant is supposed to know what
> object reference you mean when you ask for _this()?  The servant objects
> don't magically know about the POAs and servant managers, or even the
> object IDs of the CORBA objects they incarnate.  A servant can incarnate
> multiple CORBA objects at once, so _this() should really be used in only
> very special circumstances: when one knows the servant only incarnates a
> single CORBA object, and then one should always override _default_POA() to
> return the right POA.  Of course, inside an upcall, _this() is much better
> behaved.  Within the context of an upcall on a CORBA object, _this()
> on the incarnating servant should return a reference to object being
> invoked.
> So I think your solution is to stop using _this().  Keep track of the
> object references in addition to the servant object references, or use the
> POA methods ( id_to_reference(), etc...) to generate CORBA object
> references from the persistent IDs on the fly as needed.
> Kendall

More information about the omniORB-list mailing list