[omniORB] Overlapping servant lifetimes with ServantActivator (omniORB3)

[Wil_Evers@doosys.com]

Hi,

Trying last Friday's snapshot of the omniORB3 pre-release, I ran into some
unexpected behaviour.

Using a ServantActivator, I implemented a variant of the evictor pattern as
described in Henning & Vinoski's book.  The basic idea is to limit the
number of active servants in a POA to a certain maximum; if that maximum is
reached, then for every newly incarnated servant, the oldest previously
incarnated servant is deactivated.  To see what would happen under stress,
I limited the maximum number of active servants to 1. This way, the only
living servant (if any) is deactivated as soon as a request for another
object id arrives at the POA.

omniORB3 does not immediately etherialize a servant that has just been
deactivated by a call to deactivate_object() on the associated POA. That in
itself, I believe, is OK, and may even be necessary. However, in the
scenario above, incarnate() was called with an object ID I had just
deactivated, but for which the ORB had not yet invoked etherialize().  The
effect is that for a short period of time, the same object id is being
incarnated by two separate servants, causing a race condition in the
interaction with the underlying persistent store.  I *think* this is
illegal for a POA with a ServantActivator - section 11.3.5 of the CORBA 2.3
spec says:

     Incarnations of a particular object may not overlap; that is,
     incarnate shall not be invoked with a particular ObjectId while,
     within the same POA, that ObjectId is in use as the ObjectId
     of an activated object or as the argument of a call to incarnate
     or etherealize that has not completed.

The policies I set for this POA are PERSISTENT, USER_ID,
USE_SERVANT_MANAGER and RETAIN.

Did I miss something?

Thanks,

- Wil
Wil Evers, DOOSYS IT Consultants, Maarssen, Holland