Skip to main content.

5. Replicazione

4. TC Server - 5. Replicazione - 6. Virtual Heap

Ogni JVM ha un HEAP dove risiedono gli oggetti. Ogni cambiamento ad un oggetto condiviso lo possiamo vedere come una transazione terracotta, questa contiene i cambiamenti degli oggetti, o meglio solo i dati dei campi cambiati. Queste transazioni sono inviate al server e questo immediatamente, invia i cambiamenti a tutte le altre JVM coinvolte lasciando quindi il cluster consistente. Il server filtra ovviamente i dati delle transazioni in modo da mandare i cambiamenti dei soli oggetti posseduti dalle singole JVM. (se una JVM conosce uno solo degli oggetti coinvolti nella transazione, il server gli manderà i soli dati relativi a questo oggetto).

Replicazione TC

Terracotta non usa la Java Serialization per replicare i cambiamenti, gli oggetti sono tracciati e replicati a livello di campo e le transazioni contengono solo dei frammenti di un oggetto anziché tutto il grafo degli oggetti.

La Java Serialization ha come principio il salvataggio di un oggetto su uno stream, quindi anche un cambiamento ad un singolo valore, provoca la serializzazione a partire dall’oggetto radice (root) da replicare e quindi la serializzazione di tutto il grafo degli oggetti coinvolti.
L’approccio di terracotta è chiaramente molto più efficiente per mantenere sincronizzati due oggetti, infatti essa sposta attraverso il cluster, solo i dati che sono cambiati anziché ogni volta replicare tutto il grafo. La differenza di performance aumentano a dismisura se si pensa ad una struttura condivisa molto profonda.

Comunque questo approccio, a parte l’efficienza, risolve un grande problema del clustering: preservare l’identità di un oggetto.

Se la serializzazione è usata per spostare un oggetto tra i componenti di un cluster, un oggetto cambiato dovrà quindi essere deserializzato nella JVM remota e “qualcosa” dovrà sostituire l’oggetto esistente con quello passato. Questo è il motivo per cui molte altre tecniche di clustering/caching necessitano di esplicite API (GET/PUT) per la replicazione di un oggetto nel cluster.

Terracotta non ha queste restrizioni. Un oggetto condiviso nel cluster, vive nell’HEAP come qualsiasi altro oggetto. Quando un cambiamento ad un oggetto è fatto nella JVM locale, i cambiamenti sono fatti direttamente sull’oggetto dell’HEAP. Quando i cambiamenti sono fatti da una JVM remota, la transazione è ricevuta dalla JVM locale che applica questi cambiamenti sull’oggetto locale (che risiede nell’HEAP). Questo significa che c’è una e solo una istanza di un oggetto condiviso nell’HEAP di ogni JVM.

Con TC non bisogna mai richiedere la copia “fresca” dell’oggetto, e nemmeno l’inverso, non è necessario informare nessuno che l’oggetto è stato modificato. Questo perché non ci sono copie, un oggetto condiviso nel cluster è solo un semplice oggetto nell’HEAP e un oggetto condiviso si comporta come ogni altro oggetto: ogni cambiamento effettuato è disponibile immediatamente su tutti gli oggetti che posseggono la reference ad esso, che siano locali alla JVM o remoti.

Quindi è importante capire che un oggetto conserva la propria identità in una applicazione eseguita su un cluster TC (multi-JVM) come se fosse eseguita in una singola JVM.

La semplicità di Terracotta e la conservazione dell’identità di un oggetto nel cluster, rende i problemi del cluster completamente separati dai problemi di design e implementativi di una applicazione. Le capacità del cluster sono inserite a livello di JVM, fondendosi quindi con l’infrastruttura.

Cosi come il garbage collection permette la gestione della memoria in modo trasparente alla programmazione, Terracotta permette la clusterizzazione in modo ugualmente trasparente.

4. TC Server - 5. Replicazione - 6. Virtual Heap