Repository navigation
SchedulerFactoryBean no longer sets the job store's DataSource when the job store class has been customized #27709
Description
This is a regression in 5.3.13 caused by #27560. It was originally reported as a Spring Boot issue.
Activity
sbrannen commentedon Nov 20, 2021
I agree that this is a regression in terms of effective behavior for the use case described in the Spring Boot issue; however, if the user was previously specifying
org.quartz.impl.jdbcjobstore.JobStoreTXand actually wanted to use theJobStoreTXthen the application was not working as expected, since Spring previously overrodeJobStoreTXwithLocalDataSourceJobStore.Thus, if the user wants to use
JobStoreTX, they have to set theDataSourcename. Whereas, if they are fine with using Spring'sLocalDataSourceJobStorethen they should never have specifiedJobStoreTXto begin with.I'm not saying we will not revert that the change (that's currently undecided). Rather, I'm pointing out that the user configuration for an explicit job store type was previously (silently) ignored.
@jhoeller, thoughts?
jhoeller commentedon Nov 22, 2021
From my perspective, let's put a corresponding note into the documentation.
Allowing for custom variants of
LocalDataSourceJobStore, picking up theSchedulerFactoryBean-configuredDataSourcein a custom implementation, was a worthwhile enhancement there in #27560. A specifiedJobStoreTXdoes not make sense since it will effectively get overridden withLocalDataSourceJobStore, so such a property entry should get removed entirely or replaced with aorg.springframework.scheduling.quartz.LocalDataSourceJobStorevalue. In other words, I'm not really seeing a valid scenario for the previous dead-entry behavior, whereas the new behavior allows for customizations in advanced scenarios.roma2341 commentedon Nov 24, 2021
New behaviour is very confusing. I have updated spring-boot-starter-parent and couldn't run my project for several hours because "DataSource name not set" message appeared (And nothing that could help solve the issue). So, maybe this message should be more clear.
wxz0107 commentedon Dec 8, 2021
org.quartz.jobStore.class=org.springframework.scheduling.quartz.LocalDataSourceJobStore
smpshehan commentedon Dec 8, 2021
@wxz0107 Will that fix the problem? Will it get the spring.datasource as the quartz data source?
wxz0107 commentedon Dec 8, 2021
yes，i use springboot 2.5.7， it work by this configuration
smpshehan commentedon Dec 8, 2021
Oki, I upgraded to Springboot 2.6.1 and it was failing due to the same error.
So with
org.quartz.jobStore.class=org.springframework.scheduling.quartz.LocalDataSourceJobStoreI can start up the springboot app successfully. Now I need to verify that it works as before. Thanks for your suggestion.
wsdng commentedon Dec 8, 2021
I had the same problem when upgrading from Spring Boot 2.5.6 to 2.6.1.
Using LocalDataSourceJobStore is not an option because in my case the JobStore needs to be clustered.
I've been using the Annotation @QuartzDataSource to identify the dataSource.
When I got an error that the dataSource name is not set, I've added the name by setting property
"spring.quartz.properties.org.quartz.jobStore.dataSource"
This did not solve the problem, because now I got an Exception "There is no DataSource named '...'" although the dataSource bean had been instantiated at this point.
As I understand from the conversation above, there is a workaround to get things right. I would appreciate some more details on this.
smpshehan commentedon Dec 8, 2021
I use it clustered too.
org.quartz.jobStore.class=org.springframework.scheduling.quartz.LocalDataSourceJobStore
Should take the current spring data source configuration as the jdbc jobStore. That is what I believe.
wsdng commentedon Dec 9, 2021
I've got it running now. I still have the jobStore properties isClustered and driverDelegateClass in place but removed the jobStore.class.
The thing that confused me in the first place was the Quartz documentation for clustering:
"Clustering currently only works with the JDBC-Jobstore (JobStoreTX or JobStoreCMT)". I did not recognize that LocalDataSourceJobStore was a class provided by spring as a replacement for JobStoreTX and JobStoreCMT.
Thank you for the clarification.
Clarify SchedulerFactoryBean's LocalDataSourceJobStore overriding
Backported clarifications for SchedulerFactoryBean and cache annotations
Revised comment on explicit LocalDataSourceJobStore configuration
dmytro-dobrovolskyi commentedon Oct 20, 2022
Spent a lot of time on this... Apparently, if you want
@QuartzDataSourceto work you need to make your other dataSource (if you have one) as@Primarywhich is kinda implied in javadoc but it is not clear that you really have to mark it as primary.jeoningu commentedon Feb 2, 2023
I modified the QuartzConfiguration file and it works normally. Why is that?
It's my opinion!
DataSource objects are registered as spring beans even without @EnableAutoConfiguration
Even if there is no @QuartzDataSource and the spring bean name is not quartzDataSource, by some internal action Quartz JobStore finds the dataSource spring bean and makes a db connection
If my opinion is correct, can you explain the inner action of number 2 in detail?
shaikahmadbasha commentedon Mar 23, 2025
Just leaving a note here for anyone integrating Quartz for the first time.
I was trying to do a simple demo of Spring Boot with Quartz and ran into issues making it clustered. When using JobStoreTx, I got a 'DataSource not found' error. On the other hand using LocalDataSourceJobStore did not create a clustered setup. After some trial and error, I realized that setting the instanceId is crucial. Setting instanceId to AUTO made it work with LocalDataSourceJobStore.
A simple config looks like:
spring: quartz: job-store-type: jdbc properties: org: quartz: scheduler: instanceName: QuartzScheduler instanceId: AUTO jobStore: class: org.springframework.scheduling.quartz.LocalDataSourceJobStore driverDelegateClass: org.quartz.impl.jdbcjobstore.StdJDBCDelegate tablePrefix: QRTZ_ isClustered: true