Possibility to provide asynchronous or reactive cache in future versions

[linghengqian]

• There is no guidance for asynchronous or reactive cache in the existing JSR107 specification. I'm wondering if there is a roadmap for Ehcache pointing to Async Cache? This would effectively benefit Reactive types support for @Cacheable methods [SPR-14235] spring-projects/spring-framework#17920 and steer clear of something Strange operations like https://www.baeldung.com/spring-webflux-cacheable .

• For JSR107 Spec, an issue that existed in the past refers to Handle jakarta namespace? jsr107/jsr107spec#415. That issue eventually led the topic to the Jakarta community of Eclipse to continue the discussion, but the corresponding discussion thread has been silent for a long time, and the PMC of Jakarta EE proposed to open a new email at an online seminar this year to discuss the new Cache specification in Jakarta EE 10+ specification. The reason I'm not opening a new thread is that I'm not quite sure what I should do.

• For Caffeine, there is an api for asynchronous cache itself. For Cache2k, its author stated at Handle jakarta namespace? jsr107/jsr107spec#415 (comment) that its interface could serve as a starting point for a new spec, but everything is pending. I wonder what Ehcache thinks about a possible asynchronous cache specification?

[chrisdennis]

Right now there isn't the engineering capacity to take this on (given its current priority). I'm going to leave this open as it is an interesting feature. To do this justice in Ehcache would take a fairly heavy re-engineering of the internal APIs (and how information flows). Wrt to the imminent release of Loom the timing is also terrible on this kind of thing. If this is going to happen it will probably happen after the landscape has settled around Reactive/Async code in the wake of Loom and its impacts on the overhead of heavy threading.