[omniORB] omniORBpy: Pickling Objects

Duncan Grisby dgrisby@uk.research.att.com
Fri, 11 Feb 2000 10:30:58 +0000


On Thursday 10 February, Robert Sander wrote:

> As long as I can tell it seems to work. Testing to the bone is not
> so easy to me because my server object I want to pickle is an object
> in real use, so I cannot let it die.

Note that the patches I made only let you pickle object references,
not servant objects. I thought from your original message that that
was what you wanted to do, but now I'm not so sure. What precisely are
you trying to do?

Pickling a servant object is fundamentally hard, since the ORB itself
has to hold a (Python) reference to it. I think it could be done by
using some of the more advanced POA facilities like ServantManagers.
At the moment omniORBpy is based on omniORB 2.8, so it doesn't support
such things. I'm currently working on a version based on omniORB 3
which will support them.

> This must be somewhere caught, the case when the pickled object is
> no more. I think this generates an exception with the first use and
> then you have to reinit the reference (if the object now "lives" on
> another host or port). But this must be done individually, because
> the unpickled object itself is not able to tell or handle this
> situation.

An object reference is just like a pointer. If the thing it points to
no longer exists, it won't work any more. This is an inherent aspect
of the CORBA object model.

> The other thing I notice is that a TCP connection is still open when
> the request is ready and ZOPE should have dumped the object to its
> database. I do not know if this is a problem or not (at least not to
> me until now) but I think it could be better to cut this connection
> and to reestablish it when the object is unpickled. This implies
> that the object is pickled just before it is deleted, which may not
> be the normal case, so I see no solution yet.

omniORB manages TCP connections independently of object lifetimes.
They are automatically closed down after a period of activity, rather
than when the objects involved cease to exist. So it's normal that the
connections stay open.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --