-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Reintroduce in-memory repositories #4050
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
Comments
Thank you for opening this issue and for sharing your GitHub repository!
I think this became possible after resolving #4070 (which was opened and resolved after this issue). Do you agree? |
It depends. Yes, The commit can be avoided by avoiding in the same way by avoiding |
Thank you for your feedback.
OK, since we agree that it is possible, I believe this issue is resolved, or more precisely, is no more an issue after #4070. Now the fact that Spring Batch provides only a JDBC implementation of the various DAOs and that you need to supply your own implementation is not an issue in itself. What would be an issue is when Spring Batch does not provide a way for users to supply their custom implementations, but this is not the case (and your custom implementations are a good example for that). The in-memory DAOs implementations were removed for the good reasons explained in #3780 and after careful thought by the team, and there is no plan to re-introduce them. If you want, you can share your custom implementations in the Show and tell section of the project's discussions (we started using Github Discussions), and we would be happy to refer to them when appropriate. Thank you. |
@marschall I just wanted to mention that we introduced a resourceless job repository implementation in 5.2.0-M2: #4679. Any feedback is welcome to improve things for the RC and then the GA in November. |
Thanks. I didn't think of the approach of keeping the last job instance and job execution. I think this will work for many people who don't need a job explorer. I think if a |
Thank you for your feedback! I was planning to add the job explorer in the GA. |
Something I missed is |
Yes, this is mentioned in the javadoc. In hindsight, I think it is better to make it thread safe for people running multiple jobs in the same JVMs with a thread-pool based job launcher. You are welcome to open a PR if you want. |
Thinking about this in more details, I think it does not make sense to have a job explorer for a resourceless job repository. In fact, there is no resource to explore.. It is even not compatible with the current approach of using a single job instance/execution (encapsulated in the state) of the job repository. |
Expected Behavior
It should be possible to run Spring Batch integration tests without having to set up a database or if one is present without the tests committing to the database.
Current Behavior
The map based repositories were deprecated in v4 and removed in v5. However even they had the issue that they would commit to the database due to a transactional advice. This necessitates things like
JobRepositoryTestUtils#removeJobExecutions
.Using an embedded database like H2, HSQL, etc does not solve the issue. The repositories still commit. In addition this only works when no other JDBC access is used. Otherwise multiple
DataSource
andDataSourceTransactionManager
have to be juggled or the "real" database has to be used.Context
I have implemented two custom
JobRepository
andJobExplorer
implementations in marschall/spring-batch-inmemory.NullDataSource
is provided so thatJobRepositoryTestUtils
can be used.MapJobInstanceDao
,MapJobExecutionDao
,MapStepExecutionDao
andMapExecutionContextDao
). These require clean up of previous job executions, the annotation@ClearJobRepository
is provided to help with this. These avoid the performance problems of the map implementations by using copy constructors instead of Java serialization, this does not work if mutable objects are stored in contexts.I would be willing to work on a PR.
See #4016, #3834
The text was updated successfully, but these errors were encountered: