¿Cómo funciona Terracotta en esta situación?

Question

lo que permite decir que tengo una serie N servidor de tamaño constituido así:

alt text http://www.terracotta.org/web/download/attachments/43909161/ServerArrayMirrorGroup.png

Tengo un simple JavaBean/POJO:

package example; 

public class Person { 
    private OtherObject obj; 

    public void setObj(OtherObject theObj) { 
    synchronized (this) { 
     obj = theObj; 
    } 
    } 

    public OtherObject getObj() { 
    synchronized (this) { 
     return obj; 
    } 
    } 
} 

Ahora bien, si una de las llamadas de clientes Person.setObj (OtherObject) en un objeto Person en la raíz TC (estructura de datos), es el bloque sincronizado (en Person.setObj (OtherObject)) en ese cliente que se celebró:

1) Hasta el N de los servidores en el N matriz de servidores de tamaño se han sincronizado/actualizado con ese atributo Person.obj?

o

2) hasta que el servidor "activa" se ha sincronizado con que actualizó atribuyen Person.obj? Entonces los otros servidores (N-1) en la matriz se sincronizan como sea posible?

o

3) algún otro método que estoy con vistas?

Answer 1

La respuesta no es 1 ó 2. Los objetos se dividen entre los grupos espejo servidor. La primera vez que se establece este campo, se crea una transacción y ese grupo reflejado elegido para esa primera transacción "poseerá" el objeto después de eso.

Con respecto tanto a 1 como a 2, no es necesario actualizar todos los grupos de servidores activos, por lo que no hay necesidad de esperar por ninguna de esas condiciones.

Puede encontrar más información en la documentación de terracota sobre la configuración de la matriz de servidores de terracota:

• http://terracotta.org/web/display/docs/Terracotta+Server+Arrays

Desde el punto de vista de bloqueo, tendría lugar la cerradura agrupado en este objeto persona (exclusión mutua en el clúster) al realizar la modificación del objeto. El alcance del bloque sincronizado forma la transacción mencionada anteriormente. En el método getObj(), puede configurar esto como un bloqueo de lectura que permitiría varios lectores simultáneos en todo el clúster.

Answer 2

No estoy familiarizado con su implementación (Terracotta), pero desde un punto de vista JMM, debería tener un bloqueo de clúster en. Sin embargo, este ejemplo es muy simple; solo un cambio de referencia, y eso puede hacer que se convierta en algo que se parece más a una escritura volátil, y evitar por completo el bloqueo.

Pero, si usted hace cosas no triviales en su bloque sincronizado, entonces asumiría que TC pesimistamente toma un bloqueo de todo el clúster al comienzo del bloque sincronizado. Si no lo hicieran, estarían en desacuerdo con las especificaciones de JMM. como yo lo entiendo

En otras palabras, su opción n. ° 1. Por lo tanto, tenga cuidado con lo que comparte en el clúster, y use objetos inmutables y estructuras de datos java.util.concurrent. * Cuando pueda; este último obtiene un amor intrínseco especial en TC.

Answer 3

Supongamos que todos los demás tienen una referencia a su objeto y pueden tocarlo mientras/antes/después de hacerlo. Así, la solución sería añadir cerraduras y

• obtener cerradura
• modificar el objeto
• bloqueo de seguridad de

Y eso es exactamente lo que hace sincronizada ... se crea una cola y el método sincronizado no se puede llamar más de una vez ... pero el objeto subyacente podría tocarse si se hace referencia a él en alguna parte.

ver:

• http://www.terracotta.org/web/display/orgsite/Hello+Clustered+World
• http://www.terracotta.org/web/display/orgsite/Tutorials