[omniORB] RE: omniORB-list Digest, Vol 5, Issue 12

[Jelle]

Quoting JHJE (Jan Holst Jensen) (jhje at novonordisk.com):
> > I'm confused regarding the use of CORBA::release() and object lifespan
> 
> Well, haven't we all been there :-) ?

:-)

> > etc..  Suppose I got the following idl
> > 
> > interface Hello {
> > 	string say_hello();
> > };
> > interface Server {
> > 	Hello get_hello();
> > };
> [...]
> 
> > Now, if I call get_hello() from the (Java) client, what should I do?
> > call CORBA::release from the java client if I'm done with the object?
> 
> That only deletes the CORBA object reference, not the servant. Object
> references (used by CORBA clients) are completely decoupled from the
> implementations provided by servants (C++ code or whatever). This allows
> multiple object references to point to the same servant (minimizing memory
> usage) and servants may be destroyed and instantiated between requests on a
> object reference (e.g. allowing little-used servants to be "paged out").

Ah, yes, ofcourse, this clears up some things.

> What I hear you want to do, is to delete the servant from the client (thus
> invalidating the object references pointing to that servant). To be able to
> delete servants, you must add methods to the IDL that does that - e.g. add a
> "remove()" or "destroy()" method to Hello. Alternatively you could inherit
> Hello from LifeCycleObject and use it with the LifeCycle service, but that's
> far more complicated I guess :-).
> 
> In the "remove()" or "destroy()" method, the servant must deactivate the
> CORBA object(s) that point to the servant by doing something like this (Java
> server code):
> 
>       byte[] oid = rootPOA.servant_to_id(this);
>       rootPOA.deactivate_object(oid);
> 
> When all POA references to the servant are gone, and no more invocations are
> in progress on that servant, the ORB is free to delete the servant (whenever
> it sees fit - depends on the ORB implementation).

Does this apply to *every* constructed (new Hello_i()) servant (so not
only the HelloFactory(Server) servant, but also the Hello servant).

And does this also mean that every servant needs to be registered to the
rootPOA or something? 

And should I pass the rootPOA from servant to servant or is there
a more convenient way to do this? (In the visibroker example I saw
a method _default_POA())

And, finally ;-), does this have anything to do with the
RefCountServantBase class?

> > And suppose I need to construct a new Hello_i instance each time
> > get_hello() is called, how can I make sure, from the client's 
> > side, that all the Hello_i instances are deleted on the server side.
> 
> In general you can't (or shouldn't be able to) know that from the client
> side. The implementation is hidden behind the interface, so the server must
> somehow keep track of the servants that it instantiates (or let the ORB do
> it). When you call "destroy()" the server must make sure that it does what
> you intend, no matter how many servants were instantiated to service the
> client.
> 
> > And how does the java garbage collection mechanism fit into all this?
> > Are objects released automatically when they are garbage collected?
> 
> Object _references_ are released automatically when they are garbage
> collected. Servants are destroyed by the garbage collector when no POA holds
> a "pointer" to them - that is, when all their object references have been
> deactivated.

Just to clarify.

 1. construct servant using "Servant s = new Servant_i();"
 2. pass reference to servant to client using (e.g.) "s->_this();"

[... client is done and want's to clean up object ...]

 3. client calls destroy() (defined in IDL) on refence
 4. Servant_i::destroy() handles request, and calls deactivate_object()
 5. if client is a C++ program it can now release the reference using
    CORBA::release(), if it's a java client this is done by the GC.

(6) ORB will call "delete s" somewhere in the future because deactivate
    object is called on s


> Hope this helps a bit.

Yes it does, thanks for helping me out,
Jelle