[omniORB] activate_object_with_id races?

[Duncan Grisby]

On Tuesday 4 December, Mike Ladwig wrote:

> > When you give the object to the CosPer loader, does it have to have
> > the same object reference as it will have later when it has been fully
> > activated?
> 
> Yes - the object key tells the PDS what backing store to use.

How does the PDS extract the object key from the object reference?  Is
it peeking inside the IORs?

Can you provide more details about what exactly your implementation is
doing. I'm sure there must be something we can do that will let it
work...

> > If you do have to use the same reference for the loader, I'm not sure
> > what the best thing to do is. There isn't any easy way to permit
> > activations inside incarnate with the new scheme, and my reading of
> > the POA spec is that there is no requirement to do so.
> 
> Yuk.  It will be a while before I have the time to implement the new 
> persistence specification (which I pray sucks less than POS) and rewrite my 
> codebase to use it.  Could the new behavior possibly be made a compile- or 
> (preferably) run- time option, at least in omniORB 3?

If you comment out the things to do with pending operations in the
implementation of activate_object_with_id in poa.cc, that will prevent
your hang. I don't think I want to make it a run-time (or even
official compile time) option since it is only delaying the inevitable
breakage with omniORB 4. The pending operation stuff is bolted onto
the side of omniORB 3, which makes it easy to remove again; it's much
more deeply ingrained in omniORB 4.

Cheers,

Duncan.

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