May 4th, 2011, 01:39 AM
Better concurrency support for MapRepository
I observe in the forum that more and more people would find very handy to have a better concurrency support for the MapRepository implementation, as using DB for the repository is in many cases an unnecessary overhead. It always recommended to use in-mem DB instead but I think it adds a bit of an overhead too.
Would it be such a problem to make the MapRepository truly thread-safe, even for the price of decreasing the performance slightly ? I think many users (including myself) would this greatly appreciate.
May 4th, 2011, 10:30 AM
It is actually a lot harder than it looks to support all the transaction semantics concurrently. And really there is no runtime overhead with an in memory database, and it takes all of 10 seconds to find, copy and paste a dataSource definition from somewhere, or if you have Spring 3 you can create one in Java using the builder API in Spring JDBC.
If anyone wants to contribute a MapJobRepository that works reliably concurrently, then we are not going to turn it down, but it's not something I think it's worth spending time on personally.
May 4th, 2011, 02:34 PM
I can imagine it wouldn't be an easy task to make MapJobRepository work reliably concurrently , but it would make IMHO the framework much more usable.
As regards the in-memory database, I agree it's not difficult to set it up, but as I think in many cases a standard DB is used to store business data by the item writers, how would that fit together when it comes to using a transaction manager, use one defined for the standard DB or for the in-mem DB ? or mixing entitymanagerfactories for different datasources ? Also the memory footprint of the in-mem DB will be definitely bigger than the one of just maps (which also reminds me that it would be also very helpful to have methods on the repository to delete all data related to historical jobs in certain state, like COMPLETED, is this planned to implement ?)