Hi, On Wed, Mar 12, 2014 at 10:40 AM, Michael Mosmann <[email protected]>wrote:
> 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 > > Not sure why in your version of the link "are" is appended to the link and breaks it. If you remove it manually then it is also valid. > >> 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 >>>>> >>>>> >>>>> >>>> >
