¿Cómo funciona la terracota en esta situación?

Question

Entonces, digamos que tengo una matriz de servidores de tamaño N como esta:

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

Tengo un JavaBean / POJO simple:

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, si uno de los Clientes llama a Person.setObj (OtherObject) en un Objeto Person en la raíz de TC (estructura de datos), está el bloque sincronizado (en Person.setObj (OtherObject)) en ese cliente sostuvo:

1) ¿Hasta que todos los N de los Servidores en la matriz de servidores de tamaño N se hayan sincronizado / actualizado con ese atributo Person.obj?

o

2) Hasta que " active " ¿Se ha sincronizado el servidor con ese atributo Person.obj actualizado? Luego, ¿los otros servidores ( N-1 ) de la matriz se sincronizan lo más posible?

o

3) ¿Algún otro método que estoy exagerando?

Answer 1

La respuesta no es realmente 1 o 2. Los objetos se reparten en los grupos de servidores espejo. La primera vez que se establece este campo, se crea una transacción y el grupo de duplicación elegido para esa primera transacción " posee " El objeto después de eso.

Con respecto a 1 y 2, no es necesario actualizar todos los grupos de servidores activos, por lo que no es necesario esperar ninguna de estas condiciones.

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

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

Desde un punto de vista de bloqueo, el bloqueo agrupado en este objeto Persona se mantendría (exclusión mutua en todo el grupo) mientras se realiza la modificación del objeto. El alcance del bloque sincronizado forma la transacción mencionada anteriormente. En el método getObj (), podría configurarlo como un bloqueo de lectura que permitiría múltiples lectores simultáneos en el clúster.

Answer 2

Suponga que todos los demás tienen una referencia a su objeto y pueden tocarlo mientras / antes / después de que lo haga. Por lo tanto, la solución sería agregar bloqueos, y

• obtener bloqueo
• modificar el objeto
• liberar bloqueo

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

ver:

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

Answer 3

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

Pero, si haces cosas no triviales en tu bloque sincronizado, supongo que TC toma pesimista un bloqueo de todo el usuario al inicio del bloque sincronizado. Si no lo hicieran, estarían en desacuerdo con la especificación JMM. como yo lo entiendo.

En otras palabras, tu opción # 1. Por lo tanto, tenga cuidado con lo que comparte en el clúster y use objetos inmutables y java.util.concurrent. * Estructuras de datos cuando pueda: esta última está obteniendo un amor intrínseco especial en TC.