Auch in diesem Bereich hält sich die CORBA-Spezifikation ziemlich zurück und sieht nur die zwei Thread-Policies ORB_CTRL_MODEL und SINGLE_THREAD_MODEL vor. Wie der Name ORB_CTRL_MODEL bereits andeutet, ist diese Variante implementierungsabhängig.
Obwohl die CORBA-Spezifikation hier so zurückhaltend ist, bieten die meisten ORBs eine ganze Reihe an Möglichkeiten in diesem Bereich an.
Da für die meisten nicht trivialen Programme ein single-threaded concurrency Modell alleine nicht ausreicht, werden meist einige oder alle der folgenden Concurrency Models implementiert.
Single-threaded
Das Single-threaded Modell ist vor allem dann praktisch, wenn man bestehenden, nicht thread-safe Code verwenden will.
Reactive
Dieses Concurrency-Model weist große Ähnlichkeiten mit dem single-threaded Model auf. Jedoch ist es bei diesem Modell möglich, dass der Server während er auf die Antwort eines von ihm getätigten CORBA-Requests wartet, weitere Requests entgegennimmt.
Thread-per-Request
Der ORB erzeugt für jeden eingehenden Request einen eigenen Thread, in dem der Request abgearbeitet wird.
Thread-per-Session
Für jede Verbindung (Session) erzeugt der ORB einen Thread, der die eingehenden Requests auf dieser Verbindung sequentiell abarbeitet. Dieses Concurrency-Model ist vor allem bei Einsatz eines entsprechenden Clients sinnvoll, der pro geöffneter Verbindung immer nur einen konkurrenten Aufruf schickt.
Thread-Pool
Dieses Modell versucht die Performance-Nachteile des Thread-per-Request Modells dadurch in den Griff zu bekommen, dass beim Start des Servers bereits eine feste Anzahl von Worker-Threads gestartet wird, auf die die eingehenden Requests verteilt werden.
Dieser ORB unterstützt alle oben angeführten Concurrency-Modelle, wobei es keine spezielle Thread-per-Session Unterstützung auf der Client-Seite implementiert. Daher sind Probleme bei der Kombination von ORBacus (Client) und omniORB/ILU (Server) vorprogrammiert.
Zusätzlich zu den bisher genannten Concurrency-Modellen wird auch noch ein sogenanntes Threaded-Modell unterstützt, das jedoch nicht so multithreaded ist, wie der Name vermuten läßt. Im Server wird jeweils ein eigener Thread zum Empfangen, zum Senden und zum Abarbeiten von Requests gestartet. Dadurch entstehen kleine Vorteile bei der Kommunikation, aber der Server-Code selbst muss nicht multi-thread safe sein (kann als Vorteil oder auch als Nachteil gewertet werden).
Die aktuellen Versionen von omniORB (Version 2.8.0 und 3.0pre1) unterstützen derzeit nur das Thread-per-Session Concurrency-Model. Solange alle verwendeten Clients pro Verbindung nicht mehrere konkurrente Requests schicken, ist dies kein Problem. Sobald jedoch ein Client auf einer Verbindung mehrere konkurrente Requests schickt, werden diese vom Server synchronisiert und die Parallelität der Requests geht verloren.
Eine Erweiterung von omniORB um Thread-per-Request und Thread-Pool dürfte nicht allzu schwierig sein, da aufgrund der multithreaded Architektur schon genügend Vorbereitungen dafür getroffen wurden. Eine erste Version einer solchen Erweiterung findet sich auch auf meiner Web-Page (siehe [33]). Problematisch ist jedoch noch, dass omniORB beim Aufruf einer Methode einen Lock auf der Verbindung beläßt bis die Methode wirklich aufgerufen wird -- insbesondere bleibt dieser Lock während der Verarbeitung im Object Adapter bestehen, sodass ein paralleler Methodenaufruf auf der gleichen Verbindung erst danach bearbeitet werden kann.
Da Java Threads bereits fest in die Sprache integriert hat, sind alle Java-ORBs in irgendeiner Form auch multithreading-fähig, dh dass sie auf der Server-Seite zumindest das Thread-per-Request Modell unterstützen.
Eine kleine Ausnahme bildet bei den multithreading-Eigenschaften aber der im Netscape Communicator integrierte Visibroker, der als CORBA-Client offenbar Requests über eine Verbindung sequentiell abarbeitet (zusätzliche Verbdingunen werden auch nicht automatisch aufgebaut).