Writing to disk - retry mechanism?

[David Campos]

Hi,

I've been involved in a migration where we replaced ehcache-core-2.6.9 by ehcache-2.10.62 and we are facing issues writing to disk caused by ConcurrentModificationException. The cost of eliminating all those exceptions is huge and we didn't have this issue in the past because there was a retry mechanism before [please check the attached picture].

My question is: Is there a way to archive a similar retry mechanism when writing to disk?

Kind regards,

David Campos

[Chris Dennis]

The short answer here is no, there is no way to recover the old behavior. The reason for this is that you almost certainly don’t want it back.

 

The slightly longer answer is that you have six other possibilities available:

 

1. Fix the bugs in the cached types. Right now the fact that this is happening implies that at best you are caching mutable types in a ‘delayed’ store by value cache. This means what is getting cached is non-deterministic (which mutations the serializer sees are unknowable).
2. Configure the cache as copy-on-write (and maybe copy-on-read). This will make sure the serialization occurs against a detached copy of the original value both making it ‘clear’ what is being cached and also preventing the CME.
3. Implement read/write object methods that trap the exceptions and retry. This is going to be awkward, will likely force a serialization format change (which might not be acceptable) and will probably be as much work as #1 above.
4. Migrate to Ehcache 3 and write a Serializer implementation that emulates the behavior of the old 2.x disk store and risk the non-determinism.
5. Ignore the logging lines and cope with the cache evictions that these exceptions trigger.
6. The final possibility is that the structures being serialized should actually be transient and therefore should not be being serialized in the first place. Coincidentally this is really the only scenario where the old behavior isn’t masking some kind of bug.

 

Best of luck,

 

Chris

--
You received this message because you are subscribed to the Google Groups "ehcache-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ehcache-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-dev/5c202cbc-6bc4-468a-8a8c-bbd614863397n%40googlegroups.com.

[David Campos]

Thank you Chris for the very complete and useful explanation. Very appreciated!

We believe we found a way to avoid concurrent modification, which is always the best solution.

Kind regards,
David Campos