Conclusion

What have you learned in this chapter? First, job chaining can be done with the Quartz framework. You can use either of the presented approaches, but the approach without the listener implementation probably will give you fewer headaches . The other lesson I hope you take away is that job chaining is not workflow. It might seem like workflow, and you might not be convinced of this yet, but go back through the examples and try to build one of your own. Be sure to read the OSWorkflow documentation and find out about the features that we didn't mention. You should see that workflow is much more than Job chaining.

Finally, you should have learned that using OSWorkflow with Quartz is really pretty easy. All it takes is a few binaries, a few configuration files, and some workflow functions. Tie all that together with a workflow definition file, and off you go. Before you know it, you will have built a library of reusable functions and a bunch of workflows to run your business. Pretty soon, you'll have a nice little application that you can be proud of.

Appendix A. Quartz Configuration Reference

This appendix is designed to be used as a quick reference for configuring a Quartz application. Although this information is available in the Quartz documentation, this appendix provides a quicker way of looking up configuration properties and their possible values.

The Main Quartz Properties

Table A.1 lists the main scheduler properties. They are used to declare and identify the Scheduler and other top-level settings.

Table A.1. The Main Quartz Scheduler Properties

Name	Required	Type	Default Value
`org.quartz.scheduler.instanceName`	No	`String`	`'QuartzScheduler'`
`org.quartz.scheduler.instanceId`	No	`String`	`'NON_CLUSTERED'`
`org.quartz.scheduler.instance IdGenerator.class`	No	`String`	`org.quartz.simpl. SimpleInstanceIdGenerator` .
`org.quartz.scheduler.threadName`	No	`String`	`instanceName + '_QuartzSchedulerThread'`
`org.quartz.scheduler.idleWaitTime`	No	`Long`	`30000`
`org.quartz.scheduler.dbFailure RetryInterval`	No	`Long`	`15000`
`org.quartz.scheduler.classLoad Helper.class`	No	`String`	`org.quartz.simpl.Cascading ClassLoadHelper`
`org.quartz.context.key.SOME_KEY`	No	`String`	`None`
`org.quartz.scheduler. user TransactionURL`	No	`String`	`'java:comp/UserTransaction'`
`org.quartz.scheduler.wrapJob ExecutionInUserTransaction`	No	`Boolean`	`false`
`org.quartz.scheduler.job Factory.class`	No	`String`	`.quartz.simpl.Simple JobFactory`

`org.quartz.scheduler.instanceName`

Each Quartz Scheduler must be identified by a given name. The name serves as a mechanism for client code to distinguish Schedulers when multiple instances are used within the same program. If you are using the clustering features, you must use the same name for every instance in the cluster that is "logically" the same Scheduler.

`org.quartz.scheduler.instanceId`

Each Quartz Scheduler must be assigned a unique ID. The value can be any string but must be unique for all schedulers. You may use the value AUTO as the instanceId if you want the ID to be generated for you. Starting with version 1.5.1, you can customize how instance IDs are automatically generated. See the instanceIDGenerator.class property, which is described next .

`org.quartz.scheduler.instanceIdGenerator.class`

Starting with version 1.5.1, this property enables you to customize how instanceIDs are generated. This property can be used only if the property org.quartz.scheduler.instance-Id is set to AUTO . Defaults to org.quartz.simpl.SimpleInstanceIdGenerator , which generates an instance ID based on host name and time stamp.

`org.quartz.scheduler.threadName`

This can be any String that is a valid name for a Java thread. If this property is not specified, the thread will receive the Scheduler's name ( org.quartz.scheduler.instanceName ) plus the appended string '_QuartzSchedulerThread' .

`org.quartz.scheduler.idleWaitTime`

This property sets the amount of time in milliseconds that the Scheduler will wait before it requeries for available triggers when the Scheduler is otherwise idle. Normally, you should not have to tune this parameter, unless you're using XA transactions and are having problems with delayed firings of triggers that should fire immediately.

`org.quartz.scheduler.dbFailureRetryInterval`

This property sets the amount of time in milliseconds that the Scheduler will wait between retries when it has detected a loss of connectivity within the JobStore (such as to the database). This parameter is not used when using RamJobStore.

`org.quartz.scheduler.classLoadHelper.class`

This defaults to the most robust approach, which is to use the org.quartz.simpl.CascadingClassLoadHelper classwhich, in turn , uses every other ClassLoadHelper class until one works. You will probably not need to specify any other class for this property, except maybe within application servers. All the current possible ClassLoadHelper implementations can be found in the org.quartz.simpl package .

`org.quartz.context.key.SOME_KEY`

This property is used to add a name-value pair that will be placed into the "Scheduler context" as strings. (see Scheduler.getContext()) . So for example, the setting org.quartz.context.key.MyEmail = myemail@somehostcom would perform the equivalent of scheduler.getContext().put("MyEmail"," myemail@somehost.com")

`org.quartz.scheduler.userTransactionURL`

This should be set to the JNDI URL where Quartz can locate the application server's UserTransaction manager. The default value (if not specified) is java:comp/UserTransaction , which works for almost all application servers. Websphere users might need to set this property to jta/usertransaction . This is used only if Quartz is configured to use JobStoreCMT , and org.quartz.scheduler.wrapJobExecutionInUserTransaction is set to true .

`org.quartz.scheduler.wrapJobExecutionInUserTransaction`

Set this property to true if you want Quartz to start a UserTransaction before calling execute on your job. The transaction will commit after the job's execute method completes and after the JobDataMap is updated (if it is a StatefulJob ). The default value is false .

`org.quartz.scheduler.jobFactory.class`

This is the class name of the JobFactory to use. The default is org.quartz.simpl.SimpleJobFactory . You can also try the value org.quartz.simpl.PropertySettingJobFactory . A job factory is responsible for producing instances of job classes. The SimpleJobFactory class calls newInstance() on the job class. The PropertySettingJobFactory also calls newInstance() but reflectively sets the job's bean properties using the contents of the JobDataMap .