Configuring Quartz Jobs in Jmix Add-on Module to Use Separate Database (Additional Stores)

Support
#1

Issue:
I’m using Jmix add-on modules with separate databases configured via Additional Stores.

After adding the quartz-job screen to an add-on module, Quartz jobs still use the primary database instead of the add-on’s designated store.

Current Implementation:
I’ve extended the JobModelBrowse class to add custom logic, and I’m successfully using the digitalDataManager (configured with @Qualifier(“digital”)) for other operations:

Code Example:
@Autowired
@Qualifier(“digital”)
private DataManager digitalDataManager;

Question:
How can I configure Quartz jobs in add-on modules to use their respective Additional Stores rather than the main database?

configuration file:-
digital.datasource.jdbc-url=jdbc:postgresql://localhost:5432/postgres?currentSchema=modularization
digital.datasource.username=postgres
digital.datasource.password=postgres
digital.datasource.driver-class-name=org.postgresql.Driver

#2

Hello,

maybe this one will help

Kind regards,
Mladen

#3

Hi Mladen,
I’ve already gone down this path, but it’s not working. Are there any alternative methods we could explore?

#4

Hello,
I think the answer to this question requires a Jmix development team member… It would help if you could post a small example project to GitHub and link it, also, I would try to ask at the Jmix Slack channel.

Kind regards,
Mladen

#5

Hi Puneet,

Currently, all standard add-ons provided by Jmix use only the main data store. There is no such thing as “add-on’s designated store”.

Of course you can write your own custom add-ons that use your additional stores.

Please describe your situation in detail, it will help us to plan possible future improvements.

When working with DataManager, you don’t need a separate bean and a qualifier to work with entities from different data stores. The DataManager dispatches entities to their data stores automatically. See more information in the Concepts section.

Regards,
Konstantin

#6

Hi Konstantin,
Thank you for the detailed explanation! This clarifies a lot regarding the standard add-on behavior and the DataManager's automatic dispatching for multi-store entities. I’ll adjust my DataManager usage to leverage the automatic dispatching.

Regarding the Quartz jobs, I now understand that the add-on is designed for the main data store. My specific situation involves a microservice architecture where digital is a distinct, self-contained service that handles its own data and processes, including scheduled tasks. The goal is to keep all digital service-related data, including Quartz’s internal qrtz_* tables, entirely within its dedicated digital database for better isolation and independent deployment.

Currently, even with the Quartz add-on screens integrated into my digital module, the jobs are persisting to the main database, which creates a dependency I’m trying to avoid.

Given this, what would be the recommended path to achieve Quartz job persistence within my secondary digital data store?
Is there any way to configure the Jmix Quartz add-on to direct its internal table management to a specific named data store?

Any guidance on the best practice for this “add-on in secondary store” scenario would be greatly appreciated, especially as it could be a common pattern in multi-service Jmix applications.

#7

Thank you for clarifying your situation.

If your digital application is a separate (micro)service, I would suggest connecting its digital database as a main data store. Then all add-ons including Quartz will store their data in this database. If the service needs to connect to some database shared with other services, connect it as an additional data store and use @Store annotation on the entities mapped to the shared database tables.