Re: Pure in-memory IPageStore implementation?
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 …!? 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
Re: Pure in-memory IPageStore implementation?
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
Re: Pure in-memory IPageStore implementation?
Hi, 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. 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. Cheers, -Tom - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Pure in-memory IPageStore implementation?
Hi, Why not simply use LDMs to avoid entities serializations... Al my entities are non-serializable. This way I ensure I never serialize one, which might be dangerous as far as I can see. On Thu, Mar 6, 2014 at 8: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? 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? Cheers, -Tom - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Regards - Ernesto Reinaldo Barreiro
