[omniORB-dev] omni bug (patch attached)
david at riddoch.org.uk
Tue Nov 25 11:49:46 GMT 2003
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
> programming with C++" book says that if the deactivate_object method is
> 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
> 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?
More information about the omniORB-dev