[omniORB-dev] omni bug (patch attached)

[Serguei Kolos]

Hello

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

I'm not sure who is right. The problem is that when the POA goes back 
from holding to active, the object has
the state deactivatING and not deactivatED, because deactivation has 
been delayed and is not yet completed.

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

True. That's why I don't like this idea.

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

The only reason for doing that is to make sure that object deactivation
happens in some fixed time. I did not check this myself but the "Advance 
CORBA
programming with C++" book says that if the deactivate_object method is 
called
then the actual object deactivation might never happen if the object has 
a high rate
of incoming external requests. The book stays that it is a matter of luck.
This is something which worries me. Does anybody know can this really 
happen
or this is just a pure academic point.

Cheers,
Sergei