Puts with TTL

[Enrico Olivelli]

Hi all,
as most of the JCache providers give the ability to declare a TTL while issuing "puts", it there any plan to enhance the existing APIs ?

Actually the ExpiryPolicy API is very limited because there is no way to declare a different TTL based on the "semantics" of the entry.

Thanks

Enrico Olivelli
from http://blazingcache.org

[Jens Wilke]

On Freitag, 30. Dezember 2016 07:39:15 CET Enrico Olivelli wrote:
> Hi all,
> as most of the JCache providers give the ability to declare a TTL while

> issuing "puts", [ ... ]

> Actually the ExpiryPolicy API is very limited because there is no way to
> declare a different TTL based on the "semantics" of the entry.

An example of this is in https://github.com/jhalterman/expiringmap, e.g.:

map.put("connection", connection, ExpirationPolicy.ACCESSED, 5,
TimeUnit.MINUTES);

In cache2k it is possible, too:

- Set a specific expiry time in the EntryProcessor via
MutableCacheEntry.setExpiry(time)
- Update an expiry via Cache.expireAt(key, value)
- Calculate an expiry based on the loaded value in the
ExpiryPolicy

> .... it there any plan to enhance the existing APIs ?

An expiry policy that had the value as parameter was present during the
development phase of JCache but got removed quite close to the finalization of
the standard.

Implementing isn't simple in all scenarios that JCache should work in:

- It requires an index or a priority queue data structure which is O(lg n) for
updates.
- There might be additional network traffic for passing around values to
calculate the expiry time (or duration).

Although the feature is very useful, the standard shouldn't define something
that the majority is not providing. Probably, I did see it the other way
around two years ago ;)

For reference:
https://github.com/jsr107/jsr107spec/issues/126

Cheers,

Jens

--
"Everything superfluous is wrong!"

// Jens Wilke - headissue GmbH - Germany
\// https://headissue.com