search

jsr107 / jsr107spec

JSR107 Cache Specification
Apache License 2.0
415 stars 164 forks source link

Cache event for eviction by space #403

Closed neilstevenson closed 6 years ago

neilstevenson commented 6 years ago

The specification allows that an implementation can evict entries to avoid a cache running out of space, but does not specify a listener event type for this.

It's not an EXPIRED event and appears not to be a REMOVED event (based on section 8.4).

This means an implementation following the observer pattern does not have an accurate view of cache content. User initiated actions (REMOVED) and some system generated actions (EXPIRED) produce an event, but not all system generated actions.

neilstevenson commented 6 years ago

See also https://github.com/jsr107/jsr107spec/issues/261

cruftex commented 6 years ago

Can you give some examples of applications using this?

Typically I see this requirement not in applications code, but in infrastructure / middle ware code that tries to stack and knit various caching technologies and data stores together.

This means an implementation following the observer pattern does not have an accurate view of cache content.

It's a dream.

Eviction means the cache decides, because of resource constrains, that the entry is discarded from the cache. With an eviction listener in place, the entry needs to be copied, buffered and delivered to the event receiver. The whole eviction process might need to wait until the eviction listeners are run.

The existing event listeners in the spec are also not sufficient to provide an "accurate view". There is no error propagation for the listeners (for the CacheWriter there is). When I remember correctly the Spec doesn't also go into detail about the semantic guarantees in concurrent updates and listeners. The term "synchronous" is a little vague.

Within the Spec there is also no concept or definition that defines, when eviction will take place. But there needs to be an RI and TCK for the defined concepts in a Spec.

I see the desire for a feature like that, but it comes with a lot of implications and its own dynamics.

neilstevenson commented 6 years ago

Perhaps this is a documentation issue, originally triggered by this discussion https://stackoverflow.com/questions/51525150/eviction-event-listeners-for-caffeine-or-any-jvm-cache-api

Expiry events could be a flood, and you will get them eventually. So arguments the eviction events could be a flood seem to me to be no differemt

What I think this boils down to is unclear that the event set is incomplete. Either it needs to be complete (perhaps too hard) or clarified that it is incomplete.

cruftex commented 6 years ago

perhaps too hard

To be clear: It is technically feasible in some way, but it is hard to put it into a standard and have a useful and consistent behavior that applications developers can expect across all JCache implementations.

The requirement came up for cache2k as well, see here for some ideas why people want to have it: https://github.com/cache2k/cache2k/issues/59

What I think this boils down to is unclear that the event set is incomplete. Either it needs to be complete (perhaps too hard) or clarified that it is incomplete.

That's true somehow. However, you did find the original ticket where the decision was made. So the information is all there. It's quite hard to put everything that is "not supported and why" into the documentation as well.

neilstevenson commented 6 years ago

OK, happy to close

neilstevenson commented 6 years ago

@cruftex I am happy to close

This issue is mostly that the event system is incomplete - JCache allows for cache changes that the application cannot be aware of. As it would seem this is the intention, it's not a defect.

261 is very similar - what event should be produced for these missing cases, but if they're not going to be produced it's irrelevant what event type is used.