Comment Terracotta fonctionne-t-il dans cette situation?

Question

Disons que j'ai un groupe de serveurs de taille N configuré comme suit:

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

J'ai 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;
    }
  }
}

Maintenant, si l'un des clients appelle Person.setObj (OtherObject) sur un objet Personne situé dans la racine du TC (structure de données), constitue le bloc synchronisé (dans Person.setObj (OtherObject)) sur ce client a tenu:

1) Jusqu'à ce que tous les N des serveurs du groupe de serveurs de taille N aient été synchronisés / mis à jour avec cet attribut Person.obj?

ou

2) Jusqu'à la "active" " le serveur a été synchronisé avec cet attribut Person.obj mis à jour? Ensuite, les autres ( N-1 ) serveurs du groupe sont synchronisés, dans la mesure du possible?

ou

3) Une autre méthode que je regarde trop?

Answer 1

La réponse n'est pas vraiment 1 ou 2. Les objets sont répartis sur les groupes de serveurs en miroir. La première fois que ce champ est défini, une transaction est créée et le groupe de miroirs choisi pour cette première transaction sera "propre". l'objet après cela.

En ce qui concerne les groupes 1 et 2, il n'est pas nécessaire de mettre à jour tous les groupes de serveurs actifs. Il n'est donc pas nécessaire d'attendre l'une de ces conditions.

Vous trouverez plus d'informations dans la documentation Terracotta concernant la configuration du groupe de serveurs Terracotta:

• http://terracotta.org/web/display/docs/Terracotta + Serveur + tableaux

D'un point de vue de verrouillage, le verrou en cluster sur cet objet Person serait maintenu (exclusion mutuelle sur le cluster) lors de la modification de l'objet. La portée du bloc synchronisé constitue la transaction mentionnée ci-dessus. Dans la méthode getObj (), vous pouvez configurer cela comme un verrou de lecture qui autoriserait plusieurs lecteurs simultanés sur le cluster.

Answer 2

Supposons que tout le monde a une référence à votre objet et peut le toucher pendant / avant / après. Ainsi, la solution serait d'ajouter des verrous, et

• obtenir le verrou
• modifier l'objet
• déverrouiller le verrou

Et c'est exactement ce que synchronisé fait ... il crée une file d'attente et la méthode synchronisée ne peut pas être appelée plus d'une fois ... mais l'objet sous-jacent peut être touché si elle est référencée quelque part.

voir:

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

Answer 3

Je ne connais pas bien leur implémentation (Terracotta), mais du point de vue de JMM, il devrait prendre un verrou sur l'ensemble du cluster. Cependant, cet exemple est très simple. juste un changement de référence, et cela peut entraîner sa conversion en quelque chose qui ressemble plus à une écriture volatile, et éviter complètement le verrouillage.

Mais, si vous réalisez des tâches non triviales dans votre bloc synchronisé, je suppose alors que TC prend de manière pessimiste un verrou au niveau de l'utilisateur lui-même au début du bloc synchronisé. S'ils ne le faisaient pas, ils seraient en contradiction avec les spécifications JMM. comme je le comprends.

En d’autres termes, votre option n ° 1. Faites donc attention à ce que vous partagez dans le cluster et utilisez des objets immuables et des structures de données java.util.concurrent. * Lorsque vous le pouvez - ce dernier acquiert un amour intrinsèque particulier dans TC.