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 <mgrigo...@apache.org>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 <an.delb...@gmail.com>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 >> > >> > >> >> >
