a.. got it..
https://github.com/apache/wicket/compare/master...5527-inefficient-DefaultDataStore
Am 11.03.14 13:55, schrieb Martin Grigorov:
Any comments on
https://github.com/apache/wicket/compare/5527-inefficient-DefaultDataStoreare
very welcome!
It should be relatively easy to roll custom impls based on
Guava/Hazelcast/... if needed/preferred.
Martin Grigorov
Wicket Training and Consulting
On Mon, Mar 10, 2014 at 9:55 AM, Martin Grigorov <[email protected]>wrote:
I can see the benefits of adding dependency to Guava, but I can also see
many dependency conflicts caused by this.
Guava is not that strict in backward compatibility and this will lead to
problems like: an application depends on version X because of feature X1
and Wicket requires version Y that is incompatible.
On Fri, Mar 7, 2014 at 7:18 PM, Andrea Del Bene <[email protected]>wrote:
Having a flexible eviction policy would be nice, but if we decide to for
this way I would strongly recommend to NOT start implementing our own
cache solution. Instead, we should consider to adopt one of the existing
solutions (like Guava cache).
An additional consideration: what about getPage(String sessionId, int
pageId), should this also update the modification time (or maybe better:
„lastAccessTime“) of the returned page? Pages that are more frequently
requested maybe should be removed later from the cache …!?
Your suggestion would be much simpler to implement but the total size
of
this cache will be dynamic and will depend on the number of the active
sessions. But since this cache uses SoftReference for the values (the
pages) I think this won't be a problem.
We could have a (configurable) global limit for all cached pages in all
sessions, if that limit is reached, the least recently accessed/modified
page could be removed …
Cheers,
-Tom
