2010-02-17 11 views
1

J'ai un système où certains composants faiblement couplés communiquent en échangeant des messages sur JMS. Je regarde maintenant une nouvelle exigence qui conduit à une ressource partagée nécessitant une protection de l'accès par deux ou plusieurs composants en même temps (plus ou moins une instance du problème de lecture/écriture). Je cherche un moyen de coordonner l'accès à la ressource partagée sans ajouter trop de complexité supplémentaire au système. (Par exemple je ne voudrais pas ajouter un gestionnaire de verrou distribué dédié au mélange si je n'ai pas à le faire).Utilisation de JMS en tant que gestionnaire de verrou distribué?

J'ai une solution partielle dans ma tête qui utiliserait l'infrastructure JMS comme base. Fondamentalement, envoyer des messages de verrouillage aux files d'attente. S'il y a un message dans la file d'attente d'auteurs, personne ne peut poster dans cette file jusqu'à ce que le composant qui a envoyé le message le supprime à nouveau. De même, lorsqu'un lecteur commence à lire la ressource, il envoie un message à la file d'attente des lecteurs et supprime celui qui a été fait. Un écrivain ne commencerait pas à écrire tant qu'il ne verrait pas les files d'attente des lecteurs et des écrivains vides. Un lecteur ne démarre pas tant qu'il n'a pas vu une file d'attente vide.

Bien sûr, je devrais trouver un moyen de synchroniser l'accès aux deux files d'attente afin qu'un écrivain ne publie pas dans la file d'attente d'écriture pendant qu'un lecteur publie dans la file d'attente de lecture.

Peut-on tirer une telle chose avec une quantité raisonnable de travail? Existe-t-il des implémentations existantes d'un gestionnaire de verrous sur JMS? Des articles sur le sujet que vous recommanderiez?

Répondre

2

Cela semble très problématique. Trop de cas de bordure. Trop de pièges (par exemple, que se passe-t-il si le composant se bloque et ne parvient pas à retirer le verrou?) Ne gâchez pas trop avec les verrous, et certainement pas avec les verrous distribués. Utilisez les capacités du serveur JMS pour réaliser ce dont vous avez besoin en utilisant des transactions et oubliez-le.

1

Non. Vous souhaiterez peut-être vérifier Hazelcast distributed locks à la place. Hazelcast est une implémentation transactionnelle, open source (licence Apache), distribuée, distribuée de services de carte, multimap, file, sujet, verrou et exécuteur pour Java.

Questions connexes