Dans la classe BatchTriggerListner, l'implémentation de la méthode vetoJobExecution est un peu laxiste...

La méthode met en pause tous les trigger puis autorise l'exécution du job.
Or dans un environnement clusterisé, on peut se retrouver sur deux membres différents avec un appel "concurrent" à cette méthode, sur deux instances différentes (ce que ne peut pas prendre en compte le synchronized).

De ce fait, la première instance sur la machine A appelle le vetoJobExecution de son scheduler. Une ligne est insérée dans la table QRTZ_PAUSED_TRIGGER_GRPS et le système autorise l'exécution du job (retour false). Si au même moment, le scheduler de la machine B exécute la même opération, il va tenté d'insérer une ligne dans la même table, ce qui provoque une erreur "Duplicate key" lors de l'insertion dans la base.
L'exception SQL est attrapée et transformée en une JobPersistenceException (qui étend SchedulerException).
Une fois remontée jusqu'au Listener, l'exception est attrapée et le système autorise le job à s'exécuter, alors qu'un job est déjà en cours sur un autre noeud.

Un "return true" aprrès le catch me paraît important.