Environnement de cluster et service de temporisateurs
Dans un environnement à un seul serveur, vous savez quelle instance de serveur appelle la méthode timeout du bean sur un bean donné. Dans un environnement à plusieurs serveurs configurés en cluster, le comportement peut varier.
WebSphere Application Server implémente le service de temporisation Enterprise JavaBeans (EJB). Selon les besoins de votre activité, vous pouvez utiliser des temporisateurs persistants ou non persistants. Les temporisateurs persistants conviennent pour un événement périodique qui exige obligatoirement la présence d'un temporisateur au delà du cycle de vie du serveur, c'est-à-dire pour continuer d'exister pendant les arrêts et les redémarrages du serveur. Les temporisateurs persistants qui ont déjà été lancés démarrent automatiquement quand le serveur démarre ; leur stockage exige une instance de base de données. Les temporisateurs non persistants n'utilisent pas de magasin de données et sont annulés quand le serveur d'applications s'arrête ou n'est plus actif. Les temporisateurs non persistants n'existent que sur le serveur où ils ont été créés. Dans un environnement en clusters, si votre application EJB crée automatiquement un temporisateur non persistant et que cette application est répliqué en miroir sur plusieurs serveurs, chaque serveur possède alors son propre temporisateur non persistant qui s'exécute dans l'environnement de ce serveur. Un temporisateur non persistant créé programmatiquement fonctionne uniquement dans le membre de cluster où il a été créé.
Si vous configurez un temporisateur persistant dans un environnement à plusieurs serveurs en cluster, une instance de serveur peut appeler la méthode timeout sur un bean donné de plusieurs manières :
- Une base de données de temporisateurs distincte par processus serveur ou membre de cluster. Il s'agit de la configuration par défaut. Seule l'instance de serveur ou le membre du cluster ayant créé le temporisateur peut accéder à ce dernier et exécuter la méthode timeout du bean. Si le processus serveur n'est pas disponible, le temporisateur ne s'exécute pas au moment fixé et ce jusqu'au redémarrage du serveur. De plus, si un bean enterprise appelle la méthode getTimers(), les seuls temporisateurs détectés sont ceux qui ont été créés sur l'instance de serveur. Ceci peut générer un comportement inattendu lorsque le bean enterprise tente d'annuler tous les temporisateurs qui lui sont associés. Par exemple, à la suppression du bean enterprise. Cette configuration n'est PAS recommandée pour les systèmes de production.
- Base de données de temporisateurs commune ou partagée pour le cluster. Les temporisateurs peuvent être créés et ouverts à partir de n'importe quel processus serveur ou membre de cluster. Les temporisateurs créés dans un processus serveur sont détectés par la méthode getTimers() des autres processus serveur du cluster. A la suppression d'un bean entity, tous les temporisateurs, quel que soit l'endroit où ils ont été créés, sont supprimés. Toutefois, tous les temporisateurs sont exécutés sur un unique serveur du cluster, c'est-à-dire que la méthode timeout du bean est exécutée pour tous les temporisateurs sur un même serveur. Le serveur qui exécute les temporisateurs est celui qui obtient un verrouillage sur les tables de la base de données commune. Si le serveur exécutant les temporisateurs vient à ne plus être disponible, un autre serveur ou un membre du cluster prend le relais pour exécuter tous les temporisateurs au moment planifié. Cette configuration est recommandée pour tous les systèmes de production.
- Pour éviter ce problème, utilisez l'intention d'accès wsPessimisticUpdate. Avec ce type de tentative d'accès, la méthode de localisation dans votre application exécute une instruction select for update au lieu d'une sélection générique. Cela évite l'interblocage par escalade de verrous lorsque plusieurs unités d'exécution tentent d'escalader leurs verrous pour effectuer une mise à jour.
Eviter les incidents: Lorsque vous utilisez le service de temporisateurs EJB dans une application qui accède à la base de données par plusieurs unités d'exécution, le flux de l'application peut introduire des problèmes d'interblocage.gotcha


