[omniORB] activate_object_with_id races?

[Duncan Grisby]

On Tuesday 4 December, Mike Ladwig wrote:

> Is the error message not a bit untrue then?  There is no other thread 
> activating and deactivating the object.

I suppose so. omniORB 4 has a much cleaner way of detecting this
issue, and its message is

  Attempt to activate an object while it is already being
  activated. Are you calling activate_object_with_id() inside
  incarnate()?

it then throws ObjectAlreadyActive, rather than deadlocking.

Unfortunately, omniORB 3 can't tell the difference between an object
that is being activated and one that is being deactivated, so it
assumes it's being activated or deactivated by another thread, and
waits for that to occur.

[...]
> I think this is the problem;  unfortunately, this incarnate depends on my 
> implementation of the original Persistent Object Service (!) and does the 
> following:
> 
> - Create an empty object implementation
> - Activate the object with the appropriate ID (And here I hang)
> - Invoke the CosPer loader (external POS objects fill the empty object with 
> stuff in a gruesome fashion)
> - Deactivate the object
> - Return the deactivated object so that incarnate's caller can itself 
> activate it

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?  If not, you can activate it in a different POA inside
incarnate(), give the resulting object to the loader, deactivate it,
then return the servant from incarnate() to be activated as the
correct object. This has the possible advantage that it isn't open to
the race condition that a second request for the object comes in after
you have activated it for the loader, but before the loader has
finished. Of course that's only a problem if you might get more than
one concurrent request to the same object in your application.

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.

Cheers,

Duncan.

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