Come funziona la terracotta in questa situazione?

Question

Quindi diciamo che ho un array di server di dimensioni N impostato in questo modo:

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

Ho un semplice 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;
    }
  }
}

Ora se uno dei client chiama Person.setObj (OtherObject) su un oggetto persona nella radice TC (struttura dati), è il blocco sincronizzato (in Person.setObj (OtherObject)) su quel cliente deteneva:

1) Fino a quando tutti N dei server nell'array di server di dimensioni N sono stati sincronizzati / aggiornati con l'attributo Person.obj?

o

2) Fino a quando " attivo " server è stato sincronizzato con l'attributo Person.obj aggiornato? Quindi gli altri server ( N-1 ) nell'array sono sincronizzati il ??più possibile?

o

3) Qualche altro metodo che sto guardando oltre?

Answer 1

La risposta non è in realtà 1 o 2. Gli oggetti sono suddivisi in strisce nei gruppi mirror del server. La prima volta che questo campo viene impostato, viene creata una transazione e quel gruppo mirror scelto per quella prima transazione sarà "proprietario". l'oggetto dopo quello.

Rispetto a 1 e 2, non tutti i gruppi di server attivi devono essere aggiornati, quindi non è necessario attendere una di queste condizioni.

Puoi trovare maggiori informazioni nella documentazione di Terracotta sulla configurazione dell'array di server di Terracotta:

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

Da un punto di vista del blocco, il blocco cluster su questo oggetto Person verrebbe mantenuto (mutua esclusione attraverso il cluster) durante l'esecuzione della modifica dell'oggetto. L'ambito del blocco sincronizzato costituisce la transazione sopra menzionata. Nel metodo getObj (), è possibile configurarlo come un blocco di lettura che consentirebbe più lettori simultanei in tutto il cluster.

Answer 2

Supponi che tutti gli altri abbiano un riferimento al tuo oggetto e possano toccarlo mentre / prima / dopo di te. Quindi la soluzione sarebbe quella di aggiungere blocchi e

• ottieni blocco
• modifica l'oggetto
• rilascio blocco

Ed è esattamente ciò che sincronizzato fa ... crea una coda e il metodo sincronizzato non può essere chiamato più di una volta ... ma l'oggetto sottostante potrebbe essere toccato se è indicato da qualche parte.

vedi:

• http://www.terracotta.org/web/display / orgsite / Ciao + cluster + World
• http://www.terracotta.org/web/display/orgsite/Tutorials

Answer 3

Non ho familiarità con la loro implementazione (Terracotta), ma dal punto di vista di JMM, dovrebbe richiedere un blocco a livello di cluster. Tuttavia, questo esempio è molto semplice; solo una modifica di un riferimento e ciò potrebbe causare la sua conversione in qualcosa che assomiglia di più a una scrittura volatile ed evita completamente il blocco.

Ma, se fai cose non banali nel tuo blocco sincronizzato, suppongo che TC prenda pessimisticamente un blocco a livello di cluser all'inizio del blocco sincronizzato. In caso contrario, sarebbero in contrasto con le specifiche JMM. come ho capito.

In altre parole, l'opzione n. 1. Quindi, fai attenzione a ciò che condividi nel cluster e usa oggetti immutabili e java.util.concurrent. * Strutture di dati quando puoi - quest'ultimo sta ottenendo un amore intrinseco speciale in TC.