ConcurrencyManagement and EJBs splitting & architecture refactoring

[aleskandro]

1) Stateless beans: No explicit concurrency management can be configured for stateless beans. Same Stateless EJB may never be concurrently accessed by more than a single client call. Every client request uses new instance from pool. If pool becomes exhausted when a client request arrives (ex: the pool has reached its maximum size) an exception will be thrown and propagated to the remote client.

2) Stateful beans: For business methods in stateful beans, lock type is always set to WRITE (container managed concurrency). So only single client request thread can access only single methods of stateful bean. Other client requests will wait till the execution of previous thread is complete. The lock type cannot be changed (its always WRITE). Only the access-timeout value can be modified for stateful session beans.

3) Singleton beans: By default, every Singleton EJB has WRITE lock type for all methods (@Lock(LockType.WRITE)). LockType.READ is applicable only in case of singleton beans.

Also bean managed concurrency is applicable only to singleton beans. @Lock and @AccessTimeout are ignored when you use, ConcurrencyManagementType.BEAN. In this case access is restricted using synchronized keyword.

Anche questo e' interessante da leggere: http://theopentutorials.com/tutorials/java-ee/ejb3/session-beans/stsb/singleton-concurrency/

Una possibilita' potrebbe essere quindi questa (ridiscussa in calce):

ReplicaManager

Singleton1: uguale al ChordSessionBean del datamanager, tiene lock write solo per il swap finger table;

Metodi che contiene:

• findSuccessor
• fixFingers
• getReference
• swapFingerTable
• fillFingerTable

Singleton2: tiene i lock su successor e predecessor

Metodi che contiene:

• create
• join
• notify
• stabilize (necessita accesso in scrittura a finger table (solo addNode) e successor ma sono chiamate sequenziali)
• bootstrap
• moveKeys
• getLessThanAndRemove
• isPredecessor
• checkPredecessor
• getPredecessorNodeRef
• get/Set Predecessor/Successor

Stateless1:

• get
• put Assolutamente indipendenti dalla roba singleton (storage escluso)
• lookup
• write hanno accesso a fingerTable e successor in sola lettura (tramite findSuccessor)

La proposta di due singleton va solo verso la possibilita' di avere due lock diversi per fingerTable e successor/predecessor.

La proposta dello stateless per quanto puoi leggere nei link e per pura separazione.

L'intersezione dei metodi dei 3 bean costituisce una o piu' interfacce/abstract (se ce ne sono di ugale implementazione tra gli inherited ejb e mi pare di si), un po' come le abbiamo gia'. In piu' qualcosa per i metodi "comodo".

Nel dataManager estrarrei solo la lookup e la write, al momento nello stateful.

Non sono sicuro sia veramente necessaria questo "granularizzare": guardando bene il singolo lock pare basti per fingerTable e successor/predecessor quando puo' avvenire contemporaneamente lo swap e un set? anche se fosse, entrambi gli swap e i set sono molto molto veloci, sono solo puntatori che vengono riassegnati.

@eMarco che ne pensi?

[aleskandro]

@eMarco non so se ti arriva la notifica dopo l'edit, ritaggo per sicurezza