On Nov 28, 6:32 am, ap...@student.open.ac.uk wrote:
> > > I have just found a nasty race condition in my java servant which can
> > > only be explained if the CORBA event dispatching in OrbixWeb occurs
[quoted text clipped - 28 lines]
>
> -Andrew M.
Don't confuse event dispatching with POA threading policies. The ROOT
POA is single threaded by default. If you want to have multiple
servants processing messages concurrently, you have to define your own
POA with a multi-threaded policy.
I don't believe the CORBA specs says anything about how an orb
delivers the message to the POA. The processEvents operation is part
of the orb, not the POA. It's possible that the orb itself is using 2
or more threads to process incoming messages: one that reads the
socket and enqueues the message, and one or more other threads that
are associated with the processEvents function. Those thread(s) would
check the message queue, and dispatch the call to the appropriate POA.
Thus, it's possible that multiple threads in the orb layer would block
if multiple calls were send to an object associated with a single-
threaded POA.
Mark
apm35@student.open.ac.uk - 29 Nov 2007 11:38 GMT
> On Nov 28, 6:32 am, ap...@student.open.ac.uk wrote:
> > > > I have just found a nasty race condition in my java servant which can
[quoted text clipped - 3 lines]
> > > That is according the standard unless the servant is registered under
> > > single-threaded POA.
> > OrbixWeb 3.0.x is ancient and quite different to the other IONA
> > products.
> Don't confuse event dispatching with POA threading policies.
I should have mentioned earlier that OrbixWeb 3.0.x is so ancient it
is before the POA was invented. The code in question has no choice but
to use the BOA.