vmcj/nested_lock_loops 
Beim Anfordern von VM übergreifenden Sperren (Shared Locks) muss folgendes berücksichtigt werden:
Wenn innerhalb eines durch ein Shared Lock geschützten Bereiches ein weiteres Shared Lock angefordert wird, kann es bei falscher Sperrreihenfolge zu Deadlocks kommen.
Ist eine VM-übergreifende Gargabe Collection (Shared Garbage Collection) aktiv, muss eine VM, welche gerade ein Shared Lock anfordert, evtl. zunächst zur Garbage Collection beitragen, bevor sie das Shared Lock erhalten kann. Um dies zu ermöglichen, darf die Sperranforderung nicht blockieren.
Kommt es beim ersten Versuch, die Sperre zu erhalten, zu einem Timeout, tritt die VM in eine Schleife ein, bei der für kurze Zeit die Kontrolle abgegeben wird und dann erneut versucht wird, die Sperre zu erhalten.
Der Parameter vmcj/nested_lock_loops erlaubt es, die Anzahl der Schleifendurchgänge zu begrenzen:
Eigenschaften
Arbeitsgebiet | VM Container |
Einheit | Integerwert |
Standardwert | -1 |
Dynamisch änderbar | Lokal und auf allen Servern |
Wertebereich und Syntax
Folgende Werte sind möglich:
-1:Es werden unendlich viele Versuche durchgeführt, die Sperre zu setzen
n>= 0: Max. Anzahl der Versuche, die Sperre zu bekommen. Jeder Versuch dauert ca. 1 Sekunde. Falls nach Durchführung der n Sperrversuche die Sperre immer noch nicht gesetzt werden konnte, wird die Sperranforderung abgelehnt.
Empfehlung von SAP
Ändern Sie den Parameter nur, wenn Sie sicher sind, dass es sich um ein siolches Deadlock handelt und versuchen Sie dann, dieses Problem zu lösen.