Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PurgeBatchlet doesn't work with JdbcJobRepository #142

Open
amoscatelli opened this issue Mar 3, 2021 · 2 comments
Open

PurgeBatchlet doesn't work with JdbcJobRepository #142

amoscatelli opened this issue Mar 3, 2021 · 2 comments
Assignees

Comments

@amoscatelli
Copy link

amoscatelli commented Mar 3, 2021

When using JdbcJobRepository PurgeBatchlet doesn't work propertly.
By code, with JdbcJobRepository, PurgeBatchlet only uses sql and sqlFile parameters, but when using other parameters (like numberOfRecentJobExecutionsToKeep) JobExecutions are only removed from memory.

What's the sense of that ?

JdbcJobRepository should override AbstractJobRepository removeJobExecutions method and properly delete/clean every data JBeret may have been created.

JBeret users SHOULD NOT use/know any specific JBeret/implementation detail to clean the JobRepository !

Also, even if this is not the right place, Wildfly integration should also be improved.
The jberet submodule should have a parameter to specify the number of jobs to keep and use the specific JBeret implementation methods to clean the data, without the use of the PurgeBatchlet.

Absolutely this is not something end/user programmers should know about ...

I really like jsr352 specification but I had my production environment pollutted with thousands of old entries and being unable to clean them in proper way.

This causes problems like :

https://issues.redhat.com/browse/WFLY-7418
https://developer.jboss.org/thread/272830

For now, I'll switch to memory repository and use the PurgeBatchlet with a low value of numberOfRecentJobExecutionsToKeep.
Hoping this will be enough.

Thank you in advance

@chengfang chengfang self-assigned this Mar 3, 2021
@amoscatelli
Copy link
Author

amoscatelli commented Mar 4, 2021

Also, I took a look inside the JdbcJobRepository and I believe what we really need is a JpaJobRepository.
I don't think using JDBC is the proper way of handling database serialization in 2021.

We don't want to create N-th different queries for removing data for N-th different databases.

JPA just does that for us, let's not reinvent the wheel.

Furthermore, for future developments, I suggest a NoSqlJobRepository, making use of the new NoSql specification (the Document driver should be good enough for JBeret).

We don't need a specific implementation for MongoDB.

@liweinan
Copy link
Contributor

liweinan commented Jan 2, 2024

@amoscatelli Do you want to create a PR for this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants