Configuring Datasources for JobStoreCMT

As with JobStoreTX, we need to configure a Datasource so that we can use JobStoreCMT. However, JobStoreCMT requires two Datasources be configured instead of the one for JobStoreTX. One Datasource is set up as we did for the JobStoreTX: as a nonmanaged Datasource. Then we need to configure a second Datasource that is set up as a managed Datasourceone designed to be managed by the application server.

Why Does JobStoreCMT Need Two Datasources?

The original author of JobStoreCMT, Jeffrey Wescott, designed it to do its "own work" with a standard JDBC connection, whereas the work that it does on behalf of the client (such as the scheduling of the job) is performed using a JDBC connection that has its transaction under the control of the container. This design allows user interactions with Quartz to be part of their "larger" transaction, without JobStoreCMT having to use the application server's transaction manager (for example, via UserTransaction) to create and end transactions when it is doing its own internal work (such as the internal handling misfired triggers). It would be an improvement (from a configuration point of view) if JobStoreCMT did make use of UserTransaction because then only one datasource would be needed. However, when compared with the other feature requests and needed improvements, making this change has never become a top priority for the team, and JobStoreCMT continues to require two datasources.

 

Configuring the Nonmanaged Datasource

For the most part, we set up the nonmanaged DataSource in the same way that we did for JobStoreTX, except that we add one line to specify that this is the nonManagedTXDataSource:

# Add the property for the nonManagedTXDataSource
org.quartz.jobStore.nonManagedTXDataSource = myDS

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

This sets up the nonmanaged Datasource and lets the JobStore know that the nonManagedTXDataSource is called "myDS."

Configuring the Managed Datasource

The second Datasource needs to be configured as a managed Datasource. This means that Quartz uses a Datasource that the container has already created to interact with the database while performing Scheduler functions. When Quartz grabs a connection from the Datasource, there should already be a JTA transaction in progress for Quartz to schedule jobs and triggers. For example, the code calling into Quartz could be within a method on a SessionBean that has its transaction descriptor set to REQUIRED. Another approach would be for the client program to start a transaction directly through the use of javax.transaction.UserTransaction.

As with the nonmanaged Datasource, the configuration for the container-managed Datasource goes in the quartz.properties file. The following example illustrates how to set up the managed Datasource:

org.quartz.dataSource.NAME.jndiURL=jdbc/quartzDS

org.quartz.dataSource.NAME.java.naming.factory.initial=
 weblogic.jndi.WLInitialContextFactory

 org.quartz.dataSource.NAME.java.naming.provider.url=t3://localhost:7001
 org.quartz.dataSource.NAME.java.naming.security.principal=weblogic
 org.quartz.dataSource.NAME.java.naming.security.credentials=weblogic

Table 6.6 lists the properties that are available for the managed Datasource.

Table 6.6. Properties for a Datasource Used with an Application Server

Property	Required
org.quartz.dataSource.NAME.jndiURL	Yes
Description: The JNDI URL for a DataSource that is managed by your application server
org.quartz.dataSource.NAME.java.naming.factory.initial	No
Description: The (optional) class name of the JNDI InitialContextFactory that you want to use
org.quartz.dataSource.NAME.java.naming.provider.url	No
Description: The (optional) URL for connecting to the JNDI context
org.quartz.dataSource.NAME.java.naming.security.principal	No
Description: The (optional) user principal for connecting to the JNDI context
org.quartz.dataSource.NAME.java.naming.security.credentials	No
Description: The (optional) user credentials for connecting to the JNDI context

Using the properties from Table 6.6, here's an example of configuring the managed Datasource in quartz.properties.

org.quartz.dataSource.WL.jndiURL = OraDataSource
org.quartz.dataSource.WL.jndiAlwaysLookup = DB_JNDI_ALWAYS_LOOKUP
org.quartz.dataSource.WL.java.naming.factory.initial = weblogic.jndi.WLInitialContextFactory
org.quartz.dataSource.WL.java.naming.provider.url = t3://localhost:7001
org.quartz.dataSource.WL.java.naming.security.principal = weblogic
org.quartz.dataSource.WL.java.naming.security.credentials = weblogic