Discussion :

[cheachwood]

Bonjour,

Je fais actuellement une étude sur le choix d'un scheduler, Quartz s'est donc imposé très rapidement puisque très répandu.
J'ai réussi à lancer des tâches et à mettre en place le mode cluster pour haute disponibilité. Tout fonctionne à merveille pour une application.

Je décide alors de compliquer un peu les choses : je souhaite lancer deux applications avec leurs propres scheduler, trigger et job pour voir comment ce petit monde se comporte.

J'ai fait le test suivant :
- création de deux applications Java
- création de 2 jobs dans chaque appli : un avec un jobDataAsMap contenant un String, et un autre avec un jobDataAsMap avec un objet complexe
- création de 2 triggers dans chaque appli
- création d'un scheduler par appli
- je choisi de ne pas mettre en place le mode cluster et la haute dispo (donc pas d'enreg en base)
Je lance les deux appli, dans la console de la première je peux voir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
Le message du Scheduler de Quartz 1 : Job1 sur Quartz 1
Le message du Scheduler de Quartz 1 : Job3 sur Quartz 1
Le message du Scheduler de Quartz 1 : Job1 sur Quartz 1
Le message du Scheduler de Quartz 1 : Job1 sur Quartz 1
Le message du Scheduler de Quartz 1 : Job3 sur Quartz 1
Le message du Scheduler de Quartz 1 : Job1 sur Quartz 1

Et la console de la deuxième appli

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
Le message du Scheduler de Quartz 2 : Job1 sur Quartz 2
Le message du Scheduler de Quartz 2 : Job3 sur Quartz 2
Le message du Scheduler de Quartz 2 : Job1 sur Quartz 2
Le message du Scheduler de Quartz 2 : Job1 sur Quartz 2
Le message du Scheduler de Quartz 2 : Job3 sur Quartz 2
Le message du Scheduler de Quartz 2 : Job1 sur Quartz 2

Bref tout va bien, ça fonctionne super.

Ensuite j'ai fait le test suivant :
- idem test précédent +
- création d'un datasource pour chaque appli
- mise en place du mode cluster et haute disponibilité
Je lance les deux applis, et là c'est le drame :
première console :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
Le message du Scheduler de Quartz 1 : Job1 sur Quartz 1
Le message du Scheduler de Quartz 1 : Job3 sur Quartz 1
Le message du Scheduler de Quartz 1 : Job1 sur Quartz 2
Le message du Scheduler de Quartz 1 : Job1 sur Quartz 1
Le message du Scheduler de Quartz 1 : Job3 sur Quartz 1
Le message du Scheduler de Quartz 1 : Job1 sur Quartz 2

Et la console de la deuxième appli

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
 Le message du Scheduler de Quartz 2 : Job1 sur Quartz 2
 Le message du Scheduler de Quartz 2 : Job3 sur Quartz 2
 Le message du Scheduler de Quartz 2 : Job1 sur Quartz 1
 Le message du Scheduler de Quartz 2 : Job1 sur Quartz 2
 Le message du Scheduler de Quartz 2 : Job3 sur Quartz 2
 Le message du Scheduler de Quartz 2 : Job1 sur Quartz 1

OUUUUUUHHHlala ça se mélange les pinceaux grave.

Trois questions :
- en regardant d'un peu plus prêt le paramétrage de quartz dans Spring, Job 1 manipule une entrée dans le jobDataAsMap de type String et Job3 un objet complexe sérialisé (développement perso) ==> BUG?
- est-il possible de partager une seule et même base pour n applications sans que Quartz ne se mélange les pinceaux avec les objets complexes??? (Si oui comment?)
- dans la base un JobData est associé à un seul JobDetail, il ne devrait donc pas y avoir de problème : quelqu'un à-t-il eu se problème et l'a-t-il résolu (si oui comment?).

Volontairement, je n'ai pas mis de code car très volumineux (si il le faut je le ferais à la demande).

Merci pour votre patience,

Cheachwood

[cheachwood]

Bon j'ai la réponse :

> Hi,
>
> We are going to implement JDBCJobStore in our
> application which would be running in clustered
> environment. We got database script in Quartz
> distribution. We want to implement this database
> schema in generic way so that all the other
> applications could use the same database schema for
> thier JDBCJobStore implementations. I want to avoid
> generating the tables for my specific application.
>
> So my question is, the scripts which quartz provides
> in their distribution supports such kind of
> implementation?
>
> Please do let me know if there there is any sample
> application where I could find the above
> implementation.
>
> Thanks,
> Mahesh Desai

I assume that each one of your applications has its own set of jobs. I am also assuming that you are wanting to keep the business logic for each app confined to just that app. If that is the case, you won't be able to use the same set of tables for each of your apps (and the Quartz schedulers that run with them). As a result, if you did use the same set of tables (and created the resulting large clustered scheduler), you would create a situation where a scheduler instance running in app A might be called upon to run a job for app B (where the needed Job class would probably not exist).

What you probably want is a situation where each app has its own clustered scheduler. This can all be done in the same datasource and even the same schema. However, you will need a different set of Quartz tables for each of the apps and their clustered schedulers. The key to this is to use different prefixes for the table names. For example, you could replace the default prefix of QRTZ_* with QRTZAPPA_* in the sql scripts and create the tables for the app A clustered scheduler. From there, specify in quartz.properties for property org.quartz.jobStore.tablePrefix=QRTZAPPA_ . Then create another set of Quartz tables with the prefix QRTZAPPB_ . Replace with whatever prefix name you want and repeat as needed.

This is probably not what you want to hear. However, the issue that a set of these tables work w/ only one scheduler and the set of jobs that that scheduler is to run. If you have multiple schedulers (I consider a single schedule cluster as a single scheduler here) pointed at the same set of tables tend to step on one another.

Scott

En résumé, dans le même schéma il faut créer un jeu de table quartz par application avec un préfix différent : c'est pas terrible mais c'est pour l'instant la seule solution.

@+

[aymen83]

bonjour,

une autre solution si ça t'intéresse est d'utiliser un autre SGBD pour ce qui de la gestion des tables quartz en l'occurrence hsqldb.
En fait hsqldb pourra fonctionner comme étant un In-process c'est à dire que démarre quand ton application démarre et est arrêté avec ton application.

[cheachwood]

Merci pour ta réponse aymen83 mais ta solution ne m'intéresse pas, je veux que toutes mes applis utilisent un seul et même silo de données car si jamais une appli s'arrête je veux que les tâches des autres appli continuent de fonctionner.