[omniORB] Overlapping servant lifetimes with ServantActivator (omniORB3)

[David Riddoch]

Hi Wil,


Darn -- you've caught me ;-)  I realised that this was not 100% compliant
when I implemented it, but went ahead because there are significant
performance and/or complexity implications in getting it right.  I think I
can get it right efficiently, but it will be quite difficult.  This is the
one place I knew I was not quite right, and I really thought no-one would
notice, doh!

What is happening is that the object has been removed from the Active
Object Map, and then is passed to another thread to be etherealised (when 
all outstanding invocations have completed).  In the mean time another
thread comes along and incarnates an object with the same id.  What should
happen is that this incarnation should block until the origional object
has finished etherealising (see 11.3.8.17).

I can probably do this by putting some sort of placeholder into the active
object map which is only removed when etherealisation is complete.  Quite
a bit of work though, so I suggest that you work under the assumption that
it won't get fixed for a while.


Cheers,
David


On Tue, 30 Nov 1999 Wil_Evers@doosys.com wrote:

> 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?