ansaurus

Question

Answer 1

A:

Do you use a SchedulerFactoryBean? The documentation is: http://static.springsource.org/spring/docs/2.5.x/reference/scheduling.html It would completely remove the need for the actual quartz.properties and you can use the datasource you use in the rest of the application. This has obvious advantages (like reusable connections in a connection pool) and at least for me offered a somewhat easier time debugging.

Here's a snippet of how mine looked like in an older project:

<bean id="schedulerFactory" class="org.springframework.scheduling.quartz.SchedulerFactoryBean">
    <property name="quartzProperties"> <!--  quartz attributes, configurable -->
        <value>
            org.quartz.scheduler.rmi.export = false
            org.quartz.scheduler.rmi.proxy = false
            org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
            org.quartz.threadPool.threadCount = ${threadCount}
            org.quartz.threadPool.threadPriority = 5
            org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = true
            org.quartz.jobStore.useProperties = false
            org.quartz.jobStore.driverDelegateClass = ${driverDelegate}
            org.quartz.jobStore.tablePrefix = QRTZ_
            org.quartz.jobStore.isClustered = false
        </value>
    </property>
    <property name="autoStartup" value="false" /> 
    <property name="waitForJobsToCompleteOnShutdown" value="false" />
    <property name="dataSource" ref="dataSource" />
</bean>

and the datasource the usual:

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
    ....
    <property name="validationQuery" value="SELECT 1" />
    <property name="testWhileIdle" value="true" />
    <property name="testOnBorrow" value="true" />
    <property name="testOnReturn" value="true" />
</bean>

Obviously the quartzProperties are similar to the ones in the file, but I've found the general behavior of the application better once I switched from the quarts.properties to the Spring classes. It also helped that I had only one datasource actually accessing the database.

laura 2010-03-23 15:40:58

We've been using the spring classes too. However, I'll try your configuration as well. I notice that you don't have a non-transactional datasource configured. Why is that? I'm just trying to wrap my head around all this.

Khandelwal 2010-03-23 16:36:02

Interesting question. Having not actually done the datasource setup I can't really answer it though. The particular project which contained these snippets needed a transactional datasource due to the type of db queries it had, but the other projects used the same setup (one transactional datasource per project).

laura 2010-03-24 09:51:55

ansaurus

tags:

views:

answers:

quartz throws deadlocks under load

related questions