Clarify that @QuartzDataSource is the preferred mechanism for customizing Quartz's DataSource

[asakchris]

When I try to inject non primary data source to scheduler factory using SchedulerFactoryBeanCustomizer, Quartz auto configuration overrides this customization with primary data source. Refer this stack overflow qusetion

[wilkinsona]

Thanks for the report. I think the problem is that Boot itself is setting the DataSource using a SchedulerFactoryBeanCustomizer and, as it's unordered, there's nothing to stop it running after your customiser and overwriting its changes.

I think you can work around the problem by not setting spring.quartz.job-store-type and then configuring the DataSource and PlatformTransactionManager in your customiser.

[mbhave]

I think you can work around the problem by not setting spring.quartz.job-store-type and then configuring the DataSource and PlatformTransactionManager in your customiser.

@wilkinsona Would that be sufficient? The DataSource in QuartzDataSourceInitializer might also be a problem.

[asakchris]

@mbhave this is working, already verified. Let me update it in stack overflow.

[mbhave]

Thanks for verifying, @asakchris. I wonder if you already had the database for quartz initialized? Just looking at the code, it seems like the QuartzDataSourceInitializer would create the schema in the primary database. Would it be possible for you to put a breakpoint or add some debug logging to confirm that, with the workaround, the schema doesn't get created in the primary database but only in the one that you've used in your customizer? Thanks!

[wilkinsona]

Well spotted, @mbhave. You're right, the data source initialiser will be a problem unless schema initialisation has been disabled. The question on Stack Overflow has initialise-schema set to never which, I think, explains why my suggestion works.

It's an interesting problem with the customiser as it means that, even if we fix the ordering problem, it can only be used to configure a custom DataSource in some scenarios.

[mbhave]

Thanks for clarifying that, @wilkinsona. I had missed the never in the SO post. It does look like there are a few cases we'd need to consider when fixing this bug.

[mbhave]

@wilkinsona It seems like #12755 should solve this?

[wilkinsona]

I'm not sure. I'm struggling to remember what I'd figured out when I wrote "even if we fix the ordering problem, it can only be used to configure a custom DataSource in some scenarios" about the customiser.

[wilkinsona]

A problem with using the customiser to configure the DataSource is that, as @mbhave mentioned above, the initialiser will still be a problem as it'll use the wrong DataSource. I think this is what I meant when I said it would only work in some scenarios.

There are a few things that I think we should do here:

1. Order Boot's SchedulerFactoryBeanCustomizer so that users' customizers can be position before and after it.
2. Update the javadoc of SchedulerFactoryBeanCustomizer to recommend the use of QuartzDataSource for DataSource customisation.
3. Update the documentation to mention @QuartzDataSource as the preferred mechanism for configuring Quartz's data source.