Citation:
> 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.