Verwalten des gleichzeitigen Zugriffs in einer Singleton-Sitzung Bean

Question

Ich habe mit einem Kollegen eine Diskussion über Concurrency Management in Singleton Session Beans. Nach dem Lesen der Oracle documentation, wenn Sie die @ConcurrencyManagement Annotation weglassen, ist es standardmäßig container-verwaltete Nebenläufigkeit. In der Dokumentation wird es die folgenden über Container verwaltete Singleton Session Beans:

Die javax.ejb.Lock Annotation und einen javax.ejb.LockType Art der Zugriffsebene des Singletons Geschäftsmethoden zu spezifizieren verwendet oder @ Timeout-Methoden

und

Wenn keine @Lock Anmerkung auf dem Singletonklasse vorhanden ist, der Standard-Lock-Typ, @Lock (LockType.WRITE), wird an alle Unternehmen und Timeout-Methoden angewandt.

Nun, wenn Sie die Bohne mit @ConcurrencyManagement(ConcurrencyManagementType.BEAN) mit Anmerkungen versehen, dann sind Sie dafür verantwortlich, dass der Zustand der Bohne in allen Clients synchronisiert wird, um das synchronized Schlüsselwort und andere Standard-Java Concurrency-Funktionen verwenden. Der Artikel selbst sagt:

Entwickler, die Singletons mit Bean-gesteuerten Gleichzeitigkeit erstellen sind erlaubt die Programmiersprache Java Synchronisation Primitiven, wie Synchronisation und flüchtig zu verwenden, um Fehler während der gleichzeitigen Zugriff zu verhindern.

Ich habe diese nicht überall im Abschnitt über die Container-verwaltete Gleichzeitigkeit, führt mich zu glauben, dass, wenn man die Dinge selbst synchronisieren möchten, können Sie die Klasse mit @ConcurrencyManagement(ConcurrencyManagementType.BEAN) zu annotieren müssen.

Mein Kollege hat eine Bemerkung gemacht, dass "Mann ihr Leute seltsame Sachen macht", als er diese Annotation auf meiner Bohne sah, die diese Diskussion anfing.

Keine seiner Beans hat eine @ConcurrencyManagement Annotation, aber er verwendet das Schlüsselwort synchronized in der Klasse. Habe ich recht, wenn ich sage, dass eine feinkörnigere Synchronisation, die er verwendet, sinnlos ist, weil alle seine Geschäftsmethoden eine implizite @Lock(LockType.WRITE) Annotation haben? Dies würde bedeuten, dass, wenn ein Client eine seiner Methoden aufruft, kein anderer Client irgendeine Methode der Bean aufrufen kann, so dass eine explizite Synchronisation innerhalb der Methode nutzlos wäre.

Zum Beispiel, für einige Sperre myLock in synchronized (myLock) innerhalb einer seiner Geschäftsmethoden verwendet, würde es keine Konkurrenz für diese Sperre geben, da die Methoden selbst effektiv synchronisiert werden.

Korrigieren Sie mich, wenn ich falsch liege, aber es scheint, wie im Grunde seine Methoden wie folgt aussehen:

public synchronized void myMethod() { 
    // do stuff 
    synchronized (lock) { 
     // modify mutable state 
    } 
} 

public synchronized void myOtherMethod() { 
    // do other stuff 
    synchronized (lock) { 
     // modify mutable state 
    } 
} 

Unter der Annahme, dass lock in dieser Singleton Session-Bean erstellt wird nur wandelbar Zustand innerhalb der Bohne, um sie zu schützen scheint, dass es keinen Zweck erfüllt, wenn Container conceiverncy verwendet wird.

Vielen Dank im Voraus für einen Einblick in diese!

Answer 1

Im Allgemeinen stimmen Sie mit all Ihren Erwartungen überein.Es gibt einen kleinen Fall, in dem der Code Ihres Mitarbeiters tatsächlich die Synchronisationsgrundelemente verwenden könnte.

Wenn eine ejb-jar.xml-Datei vorhanden ist, kann sie festlegen, dass die Verwaltung gemeinsamer Zugriffe von der Bean verwaltet wird. Es würde wie folgt aussehen:

<enterprise-beans> 
    <session> 
     <ejb-name>MySingletonEJB</ejb-name> 
     <ejb-class>com.blah.MySingletonEJB</ejb-class> 
     <transaction-type>Bean</transaction-type> 
     ... 
    </session> 
... 
</enterprise-beans> 

Seit EJB 3, das ist wirklich eine schlechte Weise, Dinge zu tun und Anmerkungen auf jeden Fall bevorzugt, da die Konfiguration direkt mit der Quelle ist.

Answer 2

Sie haben Recht, aber es hängt davon ab, was er einsperrt, wenn das Objekt nur an diesen Singleton gebunden ist, dann ist er in der Tat ein Besserwisser, der eigentlich die Ausführung des Programms wegen der Verzögerung verlangsamt Doppelverriegelung.