Persistence #30
Comments
|
List of needed / missing parts (incomplete, gets update):
|
|
Decided to let that slip. Will concentrate in 1.0 on documentation and basic features first. I will remove the storage related classed from the implementation, they will reappear later in the year. |
|
Targeting for 1.6, since we need to look at bulk ops (1.2) and async (1.4) first. |
|
Consider integration with redisson -- a java redis front-end that provides object binding to backend persistent cache (redis). Example: redisson exposes an API where you can associate any (simple) java object's methods with redis data, and use said object concurrently on different clients, with or without local caching. I belive there is great value in merging these L1 + L2 caches into a 'user friendly' hybrid cache. |
|
Closing for the moment. Although its still on the "wish list", I don't see that we will get to it in the next months and it will most likely take a need a lot of time to complete also. I don't want to make hope that it will come some time soon by keeping the issue open. |
The current code base contains support for persistence. However it is not yet production ready. Heavy stress tests show concurrency issues, especially with the iterator() and clear().
Actually I was quite convinced to take persistence out again for 1.0 and first make sure that everything is ship shape and well documented, which is still a lot of work.
Some more thoughts and background:
The clear() implementation actually does some fancy stuff. For the clear() operation to complete in an instant and not produce any delay (a couple of seconds could bring an application down), it switched to an asynchronous buffer and later reconnects the physical storage. Maybe this could be simplified for the first step.
The JSR107 support introduced the CacheWriter and also will need event listeners. This also yields consistency issues that we won't have without them. E.g. the writes to the cache writer need to be partially ordered, so that always the cached value represents the last written value. So, the hard problems, do not necessarily go away by removing the storage....
Meanwhile I also discovered that the internal entry states do not completely support the JSR107 methods. So the next step is to do a make over of the entry locking (the third one). After that maybe some issues are gone already and we can reevaluate what we do with persistence support.
Please do comment here if you have had success or failures with the persistence support.
The text was updated successfully, but these errors were encountered: