Gestione accesso simultaneo in un bean sessione Singleton

Question

Ho avuto una discussione con un collega sulla gestione della concorrenza nei bean di sessione singleton. Da quanto ho capito, dopo aver letto lo Oracle documentation, se si omette l'annotazione @ConcurrencyManagement, il valore predefinito è la concorrenza gestita dal contenitore. Nella documentazione si afferma quanto segue riguardo container gestiti Singleton session bean:

L'annotazione javax.ejb.Lock e un tipo javax.ejb.LockType vengono utilizzati per specificare il livello di accesso dei metodi di business del singolo o @ Metodi di timeout.

e

Se non l'annotazione @Lock è presente sulla classe Singleton, il tipo di blocco di default, @Lock (LockType.WRITE), si applica a tutti i metodi di lavoro e di timeout.

Ora, se si annota il fagiolo con @ConcurrencyManagement(ConcurrencyManagementType.BEAN), allora si sono tenuti a garantire che lo stato del fagiolo è sincronizzato su tutti i client che utilizzano la parola synchronized e altre caratteristiche standard Java concorrenza. L'articolo dice anche:

sviluppatori che creano single con la concorrenza di fagioli gestiti sono ammessi utilizzare le primitive di sincronizzazione linguaggio di programmazione Java, come ad esempio la sincronizzazione e volatile, per evitare errori durante l'accesso simultaneo.

non ho visto questo in qualsiasi parte del capitolo sulla concorrenza gestito dal contenitore, mi porta a credere che, se si desidera sincronizzare le cose da soli, è necessario annotare la classe con @ConcurrencyManagement(ConcurrencyManagementType.BEAN).

Il mio collega ha fatto un commento dicendo che "voi ragazzi fate qualcosa di strano" quando ha visto questa annotazione sul mio bean, che ha dato inizio a questa discussione.

Nessuno dei suoi bean ha alcuna annotazione @ConcurrencyManagement, ma utilizza la parola chiave synchronized in tutta la classe. Ho ragione nel dire che qualsiasi sincronizzazione a grana più fine che sta usando è inutile, perché tutti i suoi metodi di business hanno un'annotazione implicita @Lock(LockType.WRITE)? Ciò significherebbe che se un client chiama uno dei suoi metodi, nessun altro client può chiamare alcun metodo del bean, quindi la sincronizzazione esplicita all'interno del metodo sarebbe inutile.

Ad esempio, per alcuni blocchi myLock utilizzati in synchronized (myLock) all'interno di uno dei suoi metodi commerciali, non ci sarebbe alcuna contesa per quel blocco poiché i metodi sono effettivamente sincronizzati.

mi corregga se sbaglio, ma sembra che i suoi metodi sostanzialmente simile a questa:

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

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

Supponendo che lock è creato in questa session bean Singleton solo per proteggere stato mutevole all'interno del chicco, si sembra che non sia utile quando si utilizza la concorrenza gestita dal contenitore.

Grazie in anticipo per qualsiasi comprensione di questo!

Answer 1

Generalmente, hai ragione di tutte le tue aspettative.C'è un caso minore in cui il codice del tuo collaboratore potrebbe effettivamente utilizzare le primitive di sincronizzazione.

Se esiste un file ejb-jar.xml, è possibile impostare la gestione della concorrenza da gestire dal bean. Sarebbe simile a questa:

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

Dal EJB 3, questo è davvero un brutto modo di fare le cose e le annotazioni sono sicuramente preferibile perché la configurazione è di destra con la fonte.

Answer 2

Sei corretto, ma dipende da cosa sta bloccando, se l'oggetto è legato a quel singleton solo allora è davvero un tuttuno che sta rallentando l'esecuzione del programma a causa del doppio bloccaggio.