2011-08-24 10 views
9

Comencé a leer sobre el bean de sesión singleton y las anotaciones utilizadas para utilizar la concurrencia administrada por contenedor. No veo la ventaja de esto en comparación con simplemente usar la palabra clave 'sincronizada', así que sospecho que hay algo importante que me falta. Considere este ejemplo del libro "Enterprise JavaBeans 3.1" por Rubinger & Burke, O'Reilly:EJB 3.1 concurrencia administrada por contenedor vs. sincronizada

@javax.ejb.Lock(javax.ejb.LockType.READ) 
public String concurrentReadOnlyMethod(){...} 

@javax.ejb.Lock(javax.ejb.LockType.WRITE) 
public void allowOnlyOneWriteAtATimeMethod(String stringToSet){...} 

¿Cómo es esto mejor que la omisión de la anotación todas Juntos en la lectura de los casos y el uso de la palabra clave synchronized en la escritura de los casos , como este:

public String concurrentReadOnlyMethod(){...} 

public synchronized void allowOnlyOneWriteAtATimeMethod(String stringToSet){...} 

Respuesta

4

Simple.

El "concurrentReadOnlyMethod" no está sincronizado en absoluto, por lo que no obtiene otro efecto secundario de la sincronización (como los efectos en las variables dentro del modelo de memoria). Además, el bloqueo READ bloqueará el bloqueo de ESCRITURA, por lo que con solo sincronizar, puede tener dos hilos ejecutando ambos métodos simultáneamente, mientras que con el bloqueo de LEER/ESCRIBIR no lo hará.

Obviamente hay más valor cuando tiene varios bloqueos de lectura y pocos bloqueos de escritura, ya que todos los bloqueos de lectura se pueden compartir y ejecutar simultáneamente, mientras que los bloqueos de escritura actúan más como un sincronizado normal.

+1

Si lo entiendo correctamente, puedo expresarlo informalmente así: dada una clase que contiene ambos métodos anteriores, con concurrencia administrada por contenedor, la semántica es "se permiten lecturas concurrentes siempre que no se esté escribiendo". La semántica del ejemplo de contraste será "se permiten lecturas concurrentes, también mientras la escritura continúa, pero solo un hilo estará escribiendo a la vez". –

+0

Sí, eso lo resume bastante bien. –

+0

¿Puede darme una referencia de esta semántica del bloqueo de LECTURA/ESCRITURA en EJB 3.1? No pude encontrarlo ni siquiera en la especificación. – illEatYourPuppies

2

Pues bien, como se ha mencionado por Will, con synchronized no se puede replicar en realidad el comportamiento de javax.ejb.Lock anotaciones, pero en realidad se puede hacer mediante el uso de ReadWriteLock cerraduras, pero esto es más trabajo en el final.

Como nota al margen, dado que las instancias singleton no se comparten en varias JVM (es decir, no son objetos distribuidos), en realidad no hay otros beneficios que Lock ofrezca facilidad de uso y fuera de la caja apoyo.

Tenga en cuenta también que "Si no se utiliza esta anotación, se supone un valor de Bloquear (ESCRIBIR)", por lo que tampoco puede deshacerse de ella.

Cuestiones relacionadas