Sperren

Es ist möglich, dass mehrere Jobs in einem System auf das gleiche Objekt zugreifen und es bearbeiten müssen. ILock definiert ein Protokoll für die Zuweisung eines exklusiven Zugriffs auf ein gemeinsam benutztes Objekt. Wenn ein Job auf das gemeinsam benutzte Objekt zugreifen muss, fordert er eine Sperre für das Objekt an. Nachdem er mit der Bearbeitung des Objektes fertig ist, gibt er das Objekt wieder frei.

Eine Sperre wird normalerweise erstellt, wenn das gemeinsam benutzte Objekt erstellt wird oder ein Plug-in zum ersten Mal darauf zugreift. Der Code, der auf das gemeinsam benutzte Objekt verweist, enthält gleichzeitig auch einen Verweis auf die Sperre. In einem ersten Schritt wird nun eine Sperre namens myLock erstellt, über die der Zugriff auf das Objekt myObject gesteuert werden kann:

   ...
   myObject = initializeImportantObject();
   IJobManager jobMan = Platform.getJobManager();
   myLock = jobMan.newLock();
   ...

Die Plattform liefert eine leistungsfähige Implementierung von ILock. Der Job-Manager bietet Exemplare dieser Sperre an, die Clients verwenden können. Diese Sperren sind über einander unterrichtet und können somit ein gegenseitiges Sperren vermeiden.(Dies wird weiter unten noch genauer erläutert.)

Wenn ein Job auf myObject zugreifen will, muss er zunächst die entsprechende Sperre anfordern. Der folgende Ausschnitt ist ein typisches Beispiel für den Umgang mit Sperren:

...
// I need to manipulate myObject, so I get its lock first.
try {
	myLock.acquire();
	updateState(myObject);  // manipulate the object
	} finally {
	lock.release();
}
...

Die Methode acquire() gibt keine Rückmeldung, bis der aufrufende Job exklusiv auf die Sperre zugreifen kann. In anderen Worten: wenn bereits ein anderer Job die Sperre angefordert hat, wird dieser Code solange blockiert, bis die Sperre wieder verfügbar ist. Beachten Sie, dass der Code, der die Sperre anfordert und myObject bearbeitet, von einem Block try eingefasst ist, so dass die Sperre freigegeben wird, sollten bei der Bearbeitung des Objekts Ausnahmebedingungen ausgelöst werden.

Der Umgang mit Sperren ist nicht sonderlich kompliziert. Sie sind auch simultan verwendbar, so dass Sie sich keine Sorgen darüber machen müssen, ob Ihr Job die gleiche Sperre möglicherweise mehrfach anfordert. Jede Sperre überprüft selbst, wie oft sie für einen bestimmten Thread angefordert und wieder freigegeben wurde, und wird von einem Job nur dann freigegeben, wenn die Anzahl der Freigaben der Anzahl der Anforderungen entspricht.

Gegenseitiges Sperren

Es wurde bereits angemerkt, dass vom Job-Manager bereitgestellte Sperren über einander unterrichtet sind und somit gegenseitiges Sperren vermeiden können. In einem einfachen Szenario soll dargestellt werden, wie gegenseitiges Sperren auftritt. Angenommen, "Job A" fordert "Sperre A" an, und versucht danach, "Sperre B" anzufordern. "Sperre B" wurde aber bereits von "Job B" angefordert und ist nun blockiert, da dieser auf "Sperre A" wartet. Diese Art von gegenseitigem Sperren zeigt ein fundamentales Designproblem auf, das auftritt, wenn Jobs Sperren verwenden. In diesem einfachen Fallbeispiel kann ein solches gegenseitiges Sperren relativ leicht vermieden werden. Mit zunehmender Anzahl an Jobs und Sperren in Ihrem Design nimmt aber die Wahrscheinlichkeit, aus Versehen eine solche gegenseitige Sperre einzubauen, stark zu.

Glücklicherweise werden Sie bei der Identifizierung solcher gegenseitiger Sperren durch die Plattform unterstützt. Wenn der Job-Manager einen solchen Zustand entdeckt, druckt er Diagnoseinformationen in das Protokoll aus, in dem der gegenseitige Sperrzustand beschrieben wird. Dann unterbricht er die gegenseitige Sperre, indem er den wartenden Jobs vorübergehenden Zugriff auf die durch einen blockierten Job angeforderten Sperren gewährt. Es ist sehr wichtig, dass Implementierungen mit mehreren Sperren sorgfältig getestet werden und alle von der Plattform gemeldeten gegenseitige Sperren korrigiert werden.