Utilisation avancée de Quartz (installation et bases d’utilisation)

Introduction

Dans notre premier article sur Quartz, on a approché l’installation et les bases d’utilisation de cette librairie.

Voyons maintenant comment l’utiliser d’une façon plus poussée à travers quelques cas d’utilisation.

Cas d’utilisation de Quartz

La force de cette librairie Java réside dans le fait qu’elle est accessible directement à partir de notre application. On peut alors imaginer plusieurs cas d’utilisation comme par exemple l’utilisation d’une base de données pour le stockage des tâches et de leurs périodicités.

Pour ce faire, il faut indiquer dans la configuration de quartz (quartz.properties) d’utiliser l’option JobStoreTX.

org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX

Il faut également lui ajouter un driver de connexion. La liste complète est disponible dans la documentation. Pour mysql, on décide d’utiliser le driver suivant :

org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.StdJDBCDelegate

Enfin, on renseigne les paramètres de connexion à la base grâce au datasource :

org.quartz.jobStore.dataSource: dsName
org.quartz.jobStore.tablePrefix: QRTZ_

org.quartz.dataSource.dsName.driver: com.mysql.jdbc.Driver
org.quartz.dataSource.dsName.URL: jdbc:mysql://domain/baseName
org.quartz.dataSource.dsName.user: user
org.quartz.dataSource.dsName.password: password

Au prochain lancement de votre application, Quartz utilisera alors la base de données indiquée et va créer ses tables de fonctionnement avec le préfixe « QRTZ_ ».

Attention, à la différence du stockage en RAM, cette fois ci les jobs seront stockés de façon permanente. A chaque lancement de votre application, Quartz se chargera de vérifier les jobs enregistrés en base et de les lancer à la période indiquée par ses triggers.

Autre point à noter : il est déconseillé de modifier directement les données en base. La librairie n’effectuant une analyse qu’au lancement de l’application, elle ne tiendra alors pas compte des modification de la base et continuera à fonctionner avec les anciennes valeurs.

Pour créer un job, le modifier, modifier sa date d’exécution, ou le supprimer, vous pouvez faire un service java et utiliser les fonctions de Quartz comme indiqué dans notre premier article.

Multi-threading

Le gros avantage de son stockage en base de données c’est de permettre à plusieurs scheduler de se connecter sur une seule et même base de données pour se répartir les tâches.

Pour ce faire, il faut rajouter les paramètres suivant dans notre fichier de properties :

org.quartz.scheduler.instanceName: SchedulerName
org.quartz.scheduler.instanceId: InstanceName

org.quartz.jobStore.dontSetAutoCommitFalse: false
org.quartz.jobStore.acquireTriggersWithinLock: true
org.quartz.jobStore.isClustered: true

Ils permettent de spécifier un nom d’instance et un id d’instance à Quartz ainsi qu’un lock lors de l’exécution d’un trigger pour éviter que deux instances essayent de lancer le même job. Le nom de l’instance peut être différent sur chaque application exécutant Quartz, en revanche, il faut que l’id soit le même.

Une fois ceci mis en place, vous pouvez lancer votre application une deuxième fois et tester la répartition des jobs. Évidemment, la répartition se produit que si la première instance Quartz est occupée. C’est alors la deuxième qui s’occupe du job suivant.

API et interactions

Comme précisé plus haut, il n’est pas recommandé de modifier les données directement en base.

C’est pour ça que l’utilisation d’un scheduler supplémentaire peut être faite dans le but de simplement modifier et re-planifier des tâches, sans pour autant le démarrer pour qu’il prenne en charge l’exécution des tâches.

Vous pouvez alors très bien développer une api/web service qui aura pour but d’attendre des requêtes précise et qui aura sa propre instance de Quartz lancée pour interpréter la requête reçue et interagir avec les jobs en temps réel.

Astuce : Sachez qu’il est également possible de passer des informations aux jobs lors de leur création en utilisant le JobDataMap qui est une Map<clé, valeur> :

JobDetail job = newJob(HelloJob.class).withIdentity("job1", "group1").build();
job.getJobDataMap().put("auth_name", "toto");

Le JobDataMap est très utile dans le cas ou vous souhaitez lancer un job avec le même code mais dont le fonctionnement change en fonction de certains paramètres. Ces données sont également stockées en base en tant qu’objet « blob » dans la dernière colonne de QRTZ_JOB_DETAILS.

Conclusion

Pour conclure, Quartz est donc très configurable ce qui le rend très puissant. Dans les cas très simple d’utilisation de scheduler, celui de Spring peut également suffire mais d’autres cas d’utilisation peuvent être trouvé à Quartz et c’est à vous de voir si il peut être utile dans vos projets.

En tout cas, chez Alinto, on l’a adopté !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *