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 > > > > > >
