next up previous contents
Next: Interceptors Up: JacORB Programming Guidev0.9 Previous: The JacORB Name Service

Thread models

JacORB allows you to set the server-side thread model for your object implementations. Three different thread models are provided: single-threading (which is actually not a thread model at all), thread-pool and thread-per-session. These are explained in the following sections.

Single Threading

This is the most trivial thread model and suppresses any kind of multi-threading on the server side. It should only be selected in cases where servers will not tolerate any concurrent accesses at all. If more than one client accesses an object implementation using this model, performance will degrade severely.

Thread Pool

In the thread-pool model, skeletons manage a set or pool of (pre-created) worker threads. Upon invocation, an idle thread is selected from the pool and asked to carry out the invocation. This thread re-joins the pool upon completion of its task.

Concurrency in this model is only constrained by the maximum number of threads in the pool. If no idle thread is available from the pool, new threads will be created on demand if the thread pool is below some maximum, which is configurable. If you have multi-threaded clients, this should be your default choice. (Actually, it is the default if no thread model is explicitly selected)

Thread per Session

This model can be regarded as a specialization of the thread-pool model. Skeleton will provide one thread per client session, i.e. connection from a client. Since JacORB manages connection resources such that there will only ever be a single connection per client address space, thread-per-session equates to thread-per-client-process.

In this model, requests from multiple clients can be carried out concurrently, while multiple (potentially concurrent) requests from a single client process will not.

Setting the Thread Model

The thread model can be set per object with the setThreadModel()-operation on the BOA. This operation must be called after creating the CORBA object with BOA.create(), but before calling BOA.obj_is_ready() for that particular object, as in the following example:

public class Server
{
   public static void main( String[] args )
   {
      try {
         org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init();
         org.omg.CORBA.BOA boa = orb.BOA_init();
         org.omg.CORBA.Object o = boa.create( new benchImpl(),
                  "IDL:jacorb/demo/benchmark/bench:1.0");

         boa.setThreadModel( o, jacorb.Orb.ThreadModel.PER_SESSION, 0, 0 );
         boa.obj_is_ready( o );
         boa.impl_is_ready();
			
      } catch (Exception e ) {
            e.printStackTrace();
      }
   }
}

The parameters for setThreadModel() in this example are:

o -- the CORBA object for which the thread model is to be set
jacorb.Orb.ThreadModel.PER_SESSION - an integer denoting the thread model (one of POOLING, PER_SESSION or SINGLE)
0 -- the maximum pool size
0 -- the minimum pool size

The last two parameters are ignored if the thread model is not jacorb.Orb.ThreadModel.POOLING. The default thread model is POOLING with the minimum and maximum pool size set to 10 and 20 respectively. It will be selected if the setThreadModel() operation is not called to set a different thread model or pool size.


next up previous contents
Next: Interceptors Up: JacORB Programming Guidev0.9 Previous: The JacORB Name Service

Gerald Brose
Tue Mar 31 08:47:04 MET DST 1998