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

Related

Категории