On Thu, Mar 6, 2014 at 10:08 AM, Tom Götz <t...@decoded.de> wrote: > > On 06.03.2014, at 08:39, Martin Grigorov <mgrigo...@apache.org> wrote: > > > On Thu, Mar 6, 2014 at 9:29 AM, Tom Götz <t...@decoded.de> wrote: > > > >> Hi there, > >> > >> I have an application that doesn’t need back-button support and also has > >> several domain objects that are not meant to be serialized. I thought it > >> could be a good idea to implement an IPageStore that skips serialization > >> and simply keeps the last n pages in memory (where n might be 5-10 > e.g.). > >> Does this sound like a reasonable plan or do you see any pitfalls with > that > >> approach? > >> > > > > Where you will store the pages ? > > I guess you will put them in the Session. Be aware that the Wicket > Session > > is stored as an attribute in the Http session. You will need custom > > ISessionStore if you want to avoid this. If you put non-Serializable > > objects in the http session then you have to make sure the http session > is > > not replicated by your web container. > > Can’t I simply use an own cache (map), just like DefaultPageStore does it > with SerializedPagesCache? With the only difference that I do not serialize > the pages …!? >
This is the second level cache as described at https://cwiki.apache.org/confluence/display/WICKET/Page+Storage. It is with application scope and uses smarter type of a map that expires entries when overloaded and on timeout. You can do the same. Just be aware of these details because otherwise you will need to cleanup on session expiration. > > > >> What about ajax requests (I’m using a lot of them)? Let’s say n=5, i.e. > >> I’m storing (only) the last 5 pages in memory, without serialization to > >> disk. I start a page, pageId==1, then I’m doing 10 ajax requests on the > >> page. Now when the user does a page reload, will he run into a > >> PageExpiredException because the requested page with id=1 is not > available > >> any more in my pageStore? > >> > > > > This is not how it works! > > Initially you store page with id X. In Ajax requests the pageId is not > > incremented, so after Ajax request the old page instance will be > overridden > > by the new one (the one with the modifications done in the ajax request) > > because it has the same pageId. > > So in your example when the user does page reload (s)he will see the last > > version of the page, i.e. the state after the last Ajax request. All > > previous states will be gone. > > > > All this is valid only if you use the same composite key for the page > store > > - sessionId+pageId. > > Ok, thanks for clarification on that point! > > Cheers, > -Tom > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
