springframework-developer

[Springframework-developer] Persistent jobs with Quartz

[<jue...@we...>]

Hi everybody,

Up to 1.0.2, our Quartz support focuses on non-persistent jobs. Of =
course, 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, =
performing its own transaction management. So if you use already use a =
connection pool within your app, you'll end up with a separate pool just =
for Quartz.

- JobStoreCMT: Quartz will use a J2EE container DataSource, and rely on =
JTA respectively EJB CMT for transaction management. You can make job =
registrations participate in enclosing transactions, but just when using =
JTA.

So what I've done is added a further option to our scheduling.quartz =
package: LocalDataSourceJobStore, using a Spring-configured DataSource =
and participating in Spring's transaction management. It is driven by =
SchedulerFactoryBean's new "dataSource" property, which will =
automatically configure that JobStore (similar to =
LocalSessionFactoryBean and LocalDataSourceConnectionProvider).

-----

Note that a JobDetail needs to respect an obvious limitation to be =
persistable with any JDBC-based JobStore: All the elements in the =
JobDataMap need to be serializable. This in particular means that =
MethodInvokingJobDetailFactoryBean does not work with persistent jobs, =
and that you cannot put 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 =
Spring's QuartzJobBean automatically applies them as bean property =
values too, just like elements in the JobDataMap.

-----

A further enhancement to SchedulerFactoryBean - unrelated to the above - =
is the "jobSchedulingDataLocations" property. Any resource specified =
there is expected to be an XML file that conforms to Quartz 1.3's =
"job_scheduling_data_1_0" DTD, defining jobs and triggers. =
SchedulerFactoryBean will 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 =
target application. I guess they're a straightforward addition to =
1.0.2's Quartz support, so I'm all for making those part of 1.0.3.

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
mailto:jue...@we...
http://www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

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
>