[omniORB] Implementation Repository

[baileyk@schneider.com]

On Wednesday 15 January, duncan@grisby.org wrote:

> Yes. In fact, the application could use a transient POA. The
> persistence is in the object reference pointing to the ImR.

OK, but doesn't that break the CORBA object model just a little?  A
transient object may die and some client sent an OBJECT_NOT_EXIST.  Later,
using the ImR based reference again it might see the object alive again?

> I don't think there's a problem in that respect. If an application
> wants to have a lot of persistent objects, it can use a persistent
> POA, and an AdapterActivator to activate it. Then, the ImR just needs
> to issue object references containing the complete object keys for the
> application. It doesn't need to know anything about what the keys
> mean. That does imply that the ImR has to have ORB specific code to
> mess with object keys, but it would work no matter what the keys mean.

You obviously know more about the encoding of IORs than I do.  From your
description I assume that the ImR will need to persist only POA identities
and not individual objects.

Here's some guesswork on my part:
The ImR generated references would encode in the object id the following:
1) The identity of the POA which hosts the target persistent object
2) The entire object key field of the target persistent object reference
(which may redundantly hold POA identity information)

Upon receiving a request for the reference the ImR would
3) Decode the object ID and find the POA identity and original object key.
4) Look in it's persistent store to find the running process or how to
start the process.
5) Start the process if needed, wait for it to register and indicate that
the required POA is available (or can be made available by an adapter
activator... or perhaps it assumes this).
6) Constructs a new reference with the original persistent object's key and
the new/existing process's host/port (or other endpoint) information (btw,
how does it obtain the new host/port or other endpoint info?)
7) redirect the client to the new reference.

Hypothetically, if another ORB handled all persistent references indirectly
through it's own ImR, it may not constrain itself to generating identical
object keys on every server restart, right?  Is it guaranteed that the
original key will still work? The other ORB may expect that key to only be
sent to invocations on it's ImR, not the server process itself.  The
omniImR would need to account for this second required level of
indirection?  Perhaps the omniImR will only be able to generate indirect
references for persistent reference which are not themselves already
indirect (i.e. pointing to yet another ImR)?  The other ImR certainly
wouldn't be able to stand in for the server object's host process.  It
wouldn't handshake with the omniImR the way you've described.

Your example:

  servant = new MyImpl();
  return omniImR::makePersistent(servant->_this());

How does this provide the ImR a POA identity to associate the reference to
(assuming there can be more than one per process)?  Does it get it out of
the object key? Or maybe it doesn't care?  Are you assuming a POA can not
migrate from one server program to another (e.g. factoring of a monolithic
server into several cooperating smaller servers)?

Just thinking out loud, playing a bit of devil's advocate.  I've encoded
stuff in object IDs before but never messed with the entire key or tried to
change the endpoint information.  I suppose I should read the source of
genior.

Kendall