Re: omni bug (patch attached)

Serguei Kolos wrote:
> 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.

Yes, I see what you mean.  I don't think there was such a distinction in 
omniORB3.  Things have changed quite a lot...

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

In omniORB3, once you call deactivate_object(), no further new requests 
will be admitted, and so you can be sure that the object would be 
etherealised as soon as any requests that have already started complete. 
  I am not confident that this is the case for omniORB4.

Duncan: can you confirm?

Cheers,
David