CORBA
Ein Objekt K1 ruft ein anderes S.M auf, welches wiederum Objekt C.M aufruft. Hier hat S sowohl Server als auch Client-Rolle
Der eigentliche Aufruf ist ein Ereignis, ebenso die Rückgabe.
A(O.M) sei das Ereignis des Methodenaufrufs samt Parameterübergabe, R(O.M) sei das Ereignis der Rückkehr und Ergebnisübergabe.
Nach A(C.M) wartet S auf R(C.M), und die Kontrolle geht an den Dispatcher des Orbs über, der beliebige weitere
Ereignisse abarbeiten wird. Bevor nun R(C.M) eintritt, kann ein weiterer Aufruf A2(S.M) eintreffen, der nun in S
einen inkonsistenten Zustand erwischt.
Bei MICO kann man der -ORBIIOPBlocking die Sockets in Blokierenden Modus schalten, um obiges Probelm zu verhindern.
Allerdings sind dann geschachtete Aufrufe auch nicht erlaubt, d.h. ein Objekt-Methode kann nicht gleichzeitig Server und Client sein. Dieses kommt aber gelegentlich vor.
Es wäre hier interressant, wie andere ORBS das Problem lösen, da ich persönlich
meine, daß geschachtelte Aufrufe nichts besonderes sein sollten. Ich stieß darauf bei Corbammims-Logger, wo jedes nennenswerte Objekt gleichzeitig Client beim Logging-Eventchannel ist.
Mit dem Transparenzziel, daß man dem Code nicht ansieht, daß eine Remote-Methode aufgerufen wird, entsteht die unübersichtlichkeit: Woher soll man wissen, ob nicht eine Bibiotheksroutine einen CORBA-Objekt aufruft ?