Re: [Springframework-developer] Persistent jobs with Quartz

[Colin S. <col...@ex...>]

This is good. Just last week I had a co-worker ask me if Spring provided=20
support for persistent Quartz jobs...

j=FCrgen h=F6ller [werk3AT] wrote:

>Hi everybody,
>
>Up to 1.0.2, our Quartz support focuses on non-persistent jobs. Of cours=
e, you can configure a persistent JobStore via Quartz properties. The out=
-of-the-box options that Quartz provides are limited, though:
>
>- JobStoreTX: Quartz will use its own Commons DBCP connection pool, perf=
orming its own transaction management. So if you use already use a connec=
tion pool within your app, you'll end up with a separate pool just for Qu=
artz.
>
>- JobStoreCMT: Quartz will use a J2EE container DataSource, and rely on =
JTA respectively EJB CMT for transaction management. You can make job reg=
istrations participate in enclosing transactions, but just when using JTA=
.
>
>So what I've done is added a further option to our scheduling.quartz pac=
kage: LocalDataSourceJobStore, using a Spring-configured DataSource and p=
articipating in Spring's transaction management. It is driven by Schedule=
rFactoryBean's new "dataSource" property, which will automatically config=
ure that JobStore (similar to LocalSessionFactoryBean and LocalDataSource=
ConnectionProvider).
>
>-----
>
>Note that a JobDetail needs to respect an obvious limitation to be persi=
stable with any JDBC-based JobStore: All the elements in the JobDataMap n=
eed to be serializable. This in particular means that MethodInvokingJobDe=
tailFactoryBean does not work with persistent jobs, and that you cannot p=
ut Spring bean references into a JobDataMap.
>
>Instead, put your bean references into the Scheduler's SchedulerContext,=
 via SchedulerFactoryBean's "schedulerContextAsMap" property (introduced =
in 1.0.2). All those elements will be exposed to all Quartz jobs, and Spr=
ing's QuartzJobBean automatically applies them as bean property values to=
o, just like elements in the JobDataMap.
>
>-----
>
>A further enhancement to SchedulerFactoryBean - unrelated to the above -=
 is the "jobSchedulingDataLocations" property. Any resource specified the=
re is expected to be an XML file that conforms to Quartz 1.3's "job_sched=
uling_data_1_0" DTD, defining jobs and triggers. SchedulerFactoryBean wil=
l automatically register those too, just like any jobs and triggers that =
are directly defined on itself.
>
>I'll commit those enhancements tomorrow, after testing them in the targe=
t application. I guess they're a straightforward addition to 1.0.2's Quar=
tz support, so I'm all for making those part of 1.0.3.
>
>Juergen
> =20
>