[omniORB] Order that remote calls are handled

[Gary D. Duzan]

In Message <99Jul27.174212edt.11649-1@gateway.imagine-sw.com> ,
   Boris Khanales <boris@imagine-sw.com> wrote:

=>Can somebody clarify what thread model OmniORB uses.
=>I thought it was thread per connection but now
=>I think it becomes thread per call.
=>What is the truth?

   It is thread per connection, though a multithreaded client may have
multiple connections to the server, which generates multiple threads on
the server side. (OmniORB automatically creates new client-server
connections as they are needed.) The same thread that is used to
receive the request from a connection and return a reply (if any) is
used to dispatch the call. There is no additional thread creation
activity at call time which you might associate with a "thread per
call" model. One result of this is that in OmniORB a "oneway" call will
wait for call processing completion before dispatching the next request
on the same connection, whereas a "thread per call" model would allow
the next request to proceed before the previous one completed.

					Gary Duzan
					GTE Laboratories

=>
=>> 
=>> In Message <Pine.LNX.4.10.9907271658060.17544-100000@voxel.ummu.umich.edu> ,
=>>    "ryan.tecco" <rtecco@voxel.ummu.umich.edu> wrote:
=>> 
=>> =>
=>> =>With CORBA in general, if you have a remote object with data members, how
=>> =>does CORBA deal with the possibility of simal. calls on the object's
=>> =>methods? 
=>> 
=>>    CORBA in general doesn't say anything about concurrent calls until
=>> the POA, and then my understanding is that it doesn't say much. You
=>> really need to check with each ORB to see what its policy is. In
=>> OmniORB, calls are handled by different threads with no built-in
=>> protection of user data, so you need to provide mutex protection
=>> yourself as needed.
=>> 
=>> 					Gary Duzan
=>> 					GTE Laboratories
=>
=>