[omniORB-dev] omni bug (patch attached)

[David Riddoch]

Hi Duncan,

Duncan Grisby wrote:
> On Monday 24 November, Serguei Kolos wrote:
> 
>>>>I believe that when the hold_requests( true ) returns there must
>>>>be no active requests for the poa_ POA and therefore must be no
>>>>active requests for the servant object, which was activated with
>>>>this POA.
> 
> The wording in the spec is not especially clear, but omniORB's current
> behaviour is definitely correct. The definition of hold_requests says
> wait_for_completion waits until there are "no actively _executing_
> requests... that is, all requests that were started prior to the state
> change have completed".
> 
> The definition of deactivate_object, on the other hand, says "An
> ObjectId that has been deactivated continues to process requests until
> there are no active requests for that ObjectId. Active requests are
> those requests that arrived before deactivate_object was called."
> That clearly includes ones that arrived while the POA was in the
> holding state. Furthermore, to avoid deadlocks or exceptions in
> objects that call themselves, new incoming requests must be accepted
> while an object is pending deactivation.

Hmmm, I'm not sure this matters.  After the POA transitions back from 
holding to active, each request that was being held checks whether the 
object is still active before continuing.  Therefore none of the 'held' 
requests will actually get executed, but instead will throw transient.

> If you put the POA in the DISCARDING state, rather than HOLDING, you
> will get exactly the behaviour you want, since that will prevent the
> queue of new incoming calls.

This may be undesirable if you have other objects activated in the same POA.

Perhaps I'm missing something, but I really can't see what is gained by 
putting the POA in the holding (or discarding) state while calling 
deactivate_object() in this case.  Either way you have to wait for all 
pending requests to complete before you can etherealise it.

Cheers,
David