[omniORB] omniORBpy: persistent IORs and/or LifeCycle support?

[Duncan Grisby]

On Tuesday 23 May, Mark Borges wrote:

> The simplest thing that comes to my mind is to perhaps use a
> persistent IOR; is this possible and/or feasible to do using
> omniORBpy? (Xs is implemented using omniORBpy/omniORB-2.8.0.) I
> skimmed the omniORB mailing list archive, but am unsure how step 2 as
> described in:
> 
>   http://www.uk.research.att.com/omniORB/archives/1997-06/0021.html
> 
> is done using omniORBpy. (Also, as this article is nearly 3 years old,
> I'm wondering if things have changed since it was written.)

If the server object really is the same object between restarts of the
process it's in, then a persistent IOR is a sensible way to proceed.
Unfortunately, with omniORB 2.8 omniORBpy can't create persistent
IORs. If you use omniORB 3, omniORBpy _can_ create them, using the
standard POA facilities.

You need to create a POA with the PERSISTENT policy (and probably also
the USER_ID policy), then activate objects with specific ids. As long
as you start the process listening on the same port each time, the IOR
will be persistent. The argument to set the port number is called
-ORBpoa_iiop_port under omniORB 3.

Something like the following will work:

-----

orb = CORBA.ORB_init(sys.argv + ["-ORBpoa_iiop_port", "1234"], CORBA.ORB_ID)
poa = orb.resolve_initial_references("RootPOA")

# Create a child POA with the right policies
ps = [poa.create_id_assignment_policy(PortableServer.USER_ID),
      poa.create_servant_retention_policy(PortableServer.RETAIN),
      poa.create_lifespan_policy(PortableServer.PERSISTENT)]

child = poa.create_POA("MyPOA", None, ps)

# Create a servant object and activate it
servant = MyServantClass()
child.activate_object_with_id("MyPersitentObject", servant)

# Get the object reference for the newly-activated object. Note that
# if you had called _this() before activate_object_with_id(), the
# object would have been implicitly activated in the root POA.
objref = servant._this()

# Activate the POA after the object is activated. If we did it
# earlier, there would be a race condition where a client may get an
# OBJECT_NOT_EXIST exception.
child._get_the_POAManager().activate()

-----

I don't think it is worth providing an interface to omniORB 2's
limited facility for creating persistent objects. It can't be mapped
onto the POA interface shown above, so it would have to use a
proprietary interface. We want to encourage people to move to omniORB
3 anyway.

> Alternatively, I read a little about the LifeCycle Service at:

The LifeCycle service won't help you here, firstly because the support
for it in omniORB 2.x requires that the server process stays alive,
secondly because omniORBpy has no interface to it, and thirdly because
omniORB 3 doesn't support it.

Cheers,

Duncan.

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