You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Tom Götz <to...@decoded.de> on 2014/03/06 08:29:17 UTC
Pure in-memory IPageStore implementation?
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Pure in-memory IPageStore implementation?
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
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 <to...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Regards - Ernesto Reinaldo Barreiro
Re: Pure in-memory IPageStore implementation?
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Mar 6, 2014 at 10:08 AM, Tom Götz <to...@decoded.de> wrote:
>
> On 06.03.2014, at 08:39, Martin Grigorov <mg...@apache.org> wrote:
>
> > On Thu, Mar 6, 2014 at 9:29 AM, Tom Götz <to...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Pure in-memory IPageStore implementation?
Posted by Tom Götz <to...@decoded.de>.
On 06.03.2014, at 08:39, Martin Grigorov <mg...@apache.org> wrote:
> On Thu, Mar 6, 2014 at 9:29 AM, Tom Götz <to...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Pure in-memory IPageStore implementation?
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Thu, Mar 6, 2014 at 9:29 AM, Tom Götz <to...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>