John, Actually the CORBA specification does not mandate the use of threads at all. It is very much possible for an ORB implementer to write an implementation that is not multi-threaded.
In reality most vendors do provide a threading model built into the ORB. So John, you are very much right that the (default) behavior is implementation specific. The thread-per-request model actually works quite well in small-medium scale applications. (This model generally supports 10+ threads at the minimum per CPU). The advantages to this are that no explicit configuration is required and requests will be handled immediately (that is, no waiting time in theory) taking full advantage of the hardware. But this model can be problematic in the case when there are a large number of requests. Here, the server would have to spawn an additional thread per request and at a certain threshold, you would find that the overhead of managing the large number of threads (switching, priorities, memory management etc) will eventually lead the system to thrash around and fail. That is, the system will probably use all available resources (CPUs primarily) but not really do anything useful. In such a case, using an event queue in front of the thread pool can be a possible solution. Here, the queue fill ups during periods of burst activity and requests are handled during periods of inactivity. Such a solution leads to trading off response time for (additional) throughput. Such a queue based solution has to configured and tuned for each (heterogeneous piece of) hardware it has to run on - since hardware [, OS and VMs] dictate the most efficient size of the queue/pool combination. Our product (the Borland Enterprise Server - our J2EE and CORBA 2.4 compliant ORB) supports the above mentioned strategies (configurable). -krish > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]On Behalf Of John Harby > Sent: Sunday, January 13, 2002 10:41 PM > To: [EMAIL PROTECTED] > Subject: Re: ORB > > > Actually a CORBA compliant POA should support thread policies > according the OMG specification (cf. sec 11.2.8.1) > > > >From: Johan Eltes <[EMAIL PROTECTED]> > >Reply-To: [EMAIL PROTECTED] > >To: [EMAIL PROTECTED] > >Subject: Re: ORB > >Date: Sun, 13 Jan 2002 22:23:11 +0100 > > > >The JavaIDL Orb creates one thread for each request. The behaviour is > >implementation-specific. Other ORBs may implement other strategies, like > >thread pools or managed queues. > > > >/Johan > > > >-----Original Message----- > >From: A mailing list for Enterprise JavaBeans development > >[mailto:[EMAIL PROTECTED]]On Behalf Of Daniel Legziel > >Sent: den 13 januari 2002 21:13 > >To: [EMAIL PROTECTED] > >Subject: ORB > > > >Hi guys, > > > >Can anyone tell me how the ORB in CORBA treats concurrent requests from > >client(s) to server(s) and vice versa? Is there a queuing dynamic that > >treats them in a FIFO manner? > > > >Any insight would be highly appreciated, > >Daniel > > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
