You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, @cached only supports 0-argument context operations, as the cache key only has the context object and the operation name. This is also done to limit the size of the cache: the current @cache is just a Java Map with no eviction policy (which guarantees that a @cached operation is only ever run once). Without an eviction policy, adding parameters to the cache key could dramatically increase the size of the cache if we are not careful.
It would be good to introduce an alternative configuration where @cached is backed by a Guava Cache instead of a Java Map, with a configurable bounded size and with an LRU eviction policy. This new approach could support operations with parameters, but would drop the guarantee that a @cached operation is only ever run once (as a less-used entry may be evicted at some point and may need to be recomputed).
To preserve backwards compatibility in Epsilon 2.x, we should keep the old no-eviction cache as the default behaviour. We may want to reconsider this default in a future 3.x release.
This issue would need both changing the EOL code, as well as extending the .dt plugins to allow for setting whether we want the old no-eviction cache (which only supports 0-arg operations), or the new LRU cache (which supports all operations).
The text was updated successfully, but these errors were encountered:
Currently,
@cached
only supports 0-argument context operations, as the cache key only has the context object and the operation name. This is also done to limit the size of the cache: the current@cache
is just a Java Map with no eviction policy (which guarantees that a@cached
operation is only ever run once). Without an eviction policy, adding parameters to the cache key could dramatically increase the size of the cache if we are not careful.It would be good to introduce an alternative configuration where
@cached
is backed by a Guava Cache instead of a Java Map, with a configurable bounded size and with an LRU eviction policy. This new approach could support operations with parameters, but would drop the guarantee that a@cached
operation is only ever run once (as a less-used entry may be evicted at some point and may need to be recomputed).To preserve backwards compatibility in Epsilon 2.x, we should keep the old no-eviction cache as the default behaviour. We may want to reconsider this default in a future 3.x release.
This issue would need both changing the EOL code, as well as extending the
.dt
plugins to allow for setting whether we want the old no-eviction cache (which only supports 0-arg operations), or the new LRU cache (which supports all operations).The text was updated successfully, but these errors were encountered: