C'est une vieille question, mais il pourrait peut-être encore être utile pour quelqu'un, alors je vais essayer d'y répondre. En supposant que la même table Timers puisse être partagée entre différents serveurs qui ne s'exécutent pas dans un cluster (en fait je pense que c'est possible), plusieurs problèmes liés à l'implémentation de TimerService apparaîtront, par exemple: supposer que chaque serveur a été déployé les mêmes Timers, sera l'instance de chaque Timer associée à différents enregistrements sur cette table ?. Si c'est le cas, la logique métier sera exécutée plus d'une fois lorsque les temporisateurs expireront. Dans le cas où le processus de déploiement génère uniquement un enregistrement par temporisateur, le service TimerService s'exécute-t-il correctement lorsque différents TimerServices tentent d'accéder/modifier les mêmes informations simultanément? D'autre part, si la motivation derrière cette idée est d'obtenir une sorte de tolérance aux pannes, il existe toujours le problème que tous vos serveurs doivent avoir déployé les mêmes temporisateurs, sinon un TimerService peut essayer d'exécuter un temporisateur qui est pas déployé sur le serveur.
La solution pour offrir la haute disponibilité est déjà implémentée et s'appelle HATimerService. Dans un cluster, il n'y a qu'une Table, mais la différence est qu'il existe un TimerService unique actif par le temps, lorsque le nœud qui exécute le TimerService échoue, un autre nœud devient le maître, donc n'existe pas d'échange d'informations entre nœuds en raison de l'information est disponible dans la base de données