On Fri, Mar 7, 2014 at 1:21 PM, Tom Götz <t...@decoded.de> wrote: > Just curious: > in 5527-inefficient-DefaultDataStore branch (8908b8f2) you are now using a > ConcurrentLinkedDeque as a cache. Why not use a map here, e.g. > ConcurrentSkipListMap with entries ordered by a timestamp or whatever? >
This is what I'm doing at the moment actually! :-) Just replacing ArrayList with ConcurrentLinkedDeque was the low hanging one. With CSLMap it is a bit more tricky to find the oldest entry in Map<String-SessionId, Map<Int-PageId, Page>> but not impossible. > > Plus: why is that cache global in terms of that it contains all pages of > all sessions? Couldn’t we have a cache that stores pages per sessionId? > This is a very good question! I was not involved in the design and implementation of these classes, so I don't know why exactly it works like this. I just know that it works this way consistently - StoredResponseMap (used by REDIRECT_TO_BUFFER) strategy also stores on application level. My guess is that the Session as part of the http session is replicated and storing this cache there will lead to more bytes being serialized when the web container does its replication logic. > > Asking because I’m currently implementing an own IPageStore and want to > learn about the mechanics and possible pitfalls. > Thanks for looking at this code and asking ! > > Cheers, > -Tom > > > On 06.03.2014, at 15:01, Martin Grigorov <mgrigo...@apache.org> wrote: > > > In the meantime I will start working on optimization. I expect that it > will > > require API changes in IPageStore interface so it may be only for Wicket > 7. > >
