Configuring a DataSource for JobStoreTX
When using persistent JobStores, Quartz requires a Datasource. A Datasource acts as a factory for database connections. In Java, all Datasources implement the java.sql.Datasource interface. Quartz doesn't provide the Datasource functionality all by itself; it delegates that responsibility. By default, Quartz can use another open source framework, called Commons DBCP, or it can use DataSources defined within an application server via JNDI lookup.
The DBCP is a Jakarta Commons project, found at http://jakarta.apache.org/commons/dbcp. The binary for this framework is included in the Quartz distribution, and you should add it to your Quartz application. You also need to add the Commons Pool library, which is included in the Quartz distribution and is used by DBCP.
When using a JobStoreTX, you must specify the Datasource properties within the quartz.properties file. This allows Quartz to create and manage the Datasource for you. Table 6.4 lists the Datasource properties that need to be configured when using a JobStoreTX.
|
Property |
Required |
|---|---|
|
org.quartz.dataSource.NAME.driver |
Yes |
|
Description: Fully qualified name of your JDBC Driver class. |
|
|
org.quartz.dataSource.NAME.URL |
Yes |
|
Description: The connection URL (host, port, and so on) for connection to your database. |
|
|
org.quartz.dataSource.NAME.user |
No |
|
Description: The username to use when connecting to your database. |
|
|
org.quartz.dataSource.NAME.password |
No |
|
Description: The password to use when connecting to your database. |
|
|
org.quartz.dataSource.NAME.maxConnections |
No |
|
Description: The maximum number of connections that the DataSource can create in its pool of connections. |
|
|
org.quartz.dataSource.NAME.validationQuery |
No |
|
Description: An optional SQL query string that the DataSource can use to detect and replace failed/corrupt connections. For example, an Oracle user might choose select table_name from user_tables, which is a query that should never fail unless the connection is actually bad. |
|
For each property listed in Table 6.4, you need to substitute a name of your choice for the NAME part of the property. It doesn't matter what it is as long as it's the same value for all properties of the Datasource. This name is used to uniquely identify the Datasource. If you need to configure multiple Datasources (which you will do when using a JobStoreCMT), each Datasource should have a unique NAME value.
Listing 6.2 shows an example of a configured Datasource for the JobStoreTX that should be added to the quartz.properties file.
Listing 6.2. An Example Quartz Datasource for Use in a Non-CMT Environment
|
org.quartz.dataSource.myDS.driver = net.sourceforge.jtds.jdbc.Driver org.quartz.dataSource.myDS.URL = jdbc:jtds:sqlserver://localhost:1433/quartz org.quartz.dataSource.myDS.user = admin org.quartz.dataSource.myDS.password = myPassword org.quartz.dataSource.myDS.maxConnections = 10 |
After adding a Datasource section to the quartz.properties file like the one from Listing 6.2, you still need to make it available to the Quartz JobStoreTX that has been configured. You do so by adding this property to the properties file:
org.quartz.jobStore.dataSource =
The value for should match the name assigned in the Datasource configuration. Using the Datasource example from Listing 6.2, you would add the following line to the quartz.properties file:
org.quartz.jobStore.dataSource = myDS
This value is then passed to the JobStoreSupport and becomes available to your JobStoreTX so that connections can be retrieved and passed to the DriverDelegate instance.