Partage d'un bloc Java synchronisé sur un cluster ou utilisation d'un verrou global?

Question

J'ai un code que je veux autoriser uniquement à accéder à un seul thread. Je sais comment y parvenir en utilisant des méthodes ou des blocs synchronized , mais cela fonctionnera-t-il dans un environnement en cluster?

L'environnement cible est WebSphere 6.0, avec 2 noeuds dans le cluster.

J'ai le sentiment que synchronisé ne fonctionnera pas, car chaque instance de l'application sur chaque nœud aura sa propre machine virtuelle, n'est-ce pas?

Ce que j'essaie de faire ici est d'effectuer des mises à jour des enregistrements de base de données au démarrage du système. Il recherchera tous les enregistrements de base de données plus anciens que la version du code et effectuera des tâches spécifiques pour les mettre à jour. Je ne souhaite qu'un seul nœud pour effectuer ces mises à niveau, car je veux m'assurer que chaque élément de travail n'est mis à niveau qu'une seule fois, et que les performances de ces mises à niveau ne sont pas un gros problème, car elles ne se produisent qu'au démarrage de l'application et ne font vraiment rien. lorsque le code a été modifié depuis le dernier démarrage.

La base de données est DB2v9, et j'y accède directement via JNDI (pas de couche ORM).

Il a été suggéré qu'un verrou global pourrait être la solution, mais je ne sais pas comment faire.

Quelqu'un at-il des indicateurs dans ce domaine?

Merci!

Answer 1

Vous avez raison de dire que la synchronisation entre processus ne fonctionnera pas avec les structures de synchronisation Java. Heureusement, votre problème n’est pas vraiment un problème de synchronisation de code, mais plutôt de synchronisation des interactions avec la base de données.

La bonne façon de traiter ce problème consiste à utiliser des verrous au niveau de la base de données. Vous avez probablement une table contenant une version du schéma de base de données, vous devez donc vous assurer de verrouiller cette table pour la durée du processus de démarrage / mise à niveau.

Les appels spécifiques à sql / db impliqués seraient probablement plus clairs si vous spécifiiez votre type de base de données (DB2?) et votre méthode d'accès (raw SQL, jpa, etc.).

Mise à jour (8/4/2009 14h39) : Je suggère LOCK TABLE sur une table contenant le numéro de version du schéma. Cela sérialisera l'accès à cette table, empêchant deux instances d'exécuter simultanément le code de mise à niveau.

Answer 2

Oui, vous avez raison de dire que les blocs synchronisés ne fonctionnent pas sur un cluster. Comme vous l'avez dit, la raison en est que chaque nœud a sa propre machine virtuelle Java.

Cependant, il existe des moyens de faire en sorte que les blocs synchronisés fonctionnent dans un cluster comme dans un environnement à un seul noeud. Le moyen le plus simple consiste à utiliser un produit tel que Terracotta , qui gérera la coordination des threads entre différentes machines virtuelles afin que les contrôles de concurrence normaux peut être utilisé à travers le cluster. De nombreux articles expliquant comment cela fonctionne, tels que Introduction à OpenTerracotta .

Il existe bien sûr d’autres solutions. Cela dépend surtout de ce que vous voulez vraiment réaliser ici. Je ne voudrais pas utiliser les verrous de base de données pour la synchronisation si vous devez évoluer, contrairement à DB. Mais je vous exhorte vraiment à trouver une solution prête à l'emploi, car la synchronisation avec les clusters est une tâche fastidieuse:)

Answer 3

Vous pouvez utiliser une grille de données en mémoire telle que http://www.hazelcast.com/ pour cela aussi. Cette structure de données distribuée prend en charge le verrouillage.

Answer 4

Puisque vous parlez de 2 machines, vous n'avez même pas de mémoire partagée, il n'y a donc rien à synchroniser.

Nous faisons quelque chose de similaire avec notre base de données. Ceci est réalisé en ajoutant le contrôle de version des enregistrements dans la table. C’est ce que vous devriez faire,

1. Ajouter une colonne pour la version enregistrement / ligne.
2. Parcourez la logique pour vérifier si l'enregistrement doit être mis à jour.
3. Lorsque vous mettez à jour un enregistrement, assurez-vous que la version de l'enregistrement dans la base de données est la même que celle que vous avez.
4. Augmentez la version à chaque fois que vous écrivez dans la base de données.

Un seul serveur doit mettre à jour la base de données si vous suivez ces règles.

Answer 5

Ne pourriez-vous pas simplement verrouiller la table (ou toute la base de données) pour les mises à jour, ainsi, lorsque le premier nœud obtenu le verrouillerait, tous les autres nœuds ne pourraient pas écrire. Les noeuds suivants attendraient et, lorsque le verrou serait libéré, le code serait mis à jour et aucune mise à jour d'enregistrement ne serait nécessaire.