Second Level Cache

[mfs <fa...@gmail.com>]

Guys,

I am yet bringing the same question again, regarding the SLCSS and the need
to maintain it the older versions of the page on the disk or otherwise...and
would really appreciate if some of my questions could be addressed here..

Before i go into Second Level Cache..i would say that i still can comprehend
the reason to store the latest version of a page (or the last accessed
version) in the session, since a user can click the browser back button and
access it (though by default this wouldnt happen and we would need to set
the header to "no-store" so that a request is sent to the server instead of
loading the last page from browser-cache)..or if we have a back button
functionality explicitly implemented on our page...or yet otherwise if the
user clicks the refresh button we can still utilize the last page-version..

Coming to the Second Level Cache, i still find it hard to understand as to
why and when would one come to the need of accessing the old serialized page
versions (other than the latest) ? what would those use-cases be when would
be want to access the earlier versions of a page ? Can someone point me some
of those scenarios...

Thanks in advance and Regards,

Farhan.





-- 
View this message in context: http://www.nabble.com/Second-Level-Cache-tf4824369.html#a13803095
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Second Level Cache

[Matej Knopp <ma...@gmail.com>]

When user presses the back button, wicket need to reconstruct the
previous page instance. And the previous page instance is stored in
second level cache. Wichet is a statefull framework, it maintains page
instances. Most of the time the url only contains page id and page
version. This is used to pull the right instance from second level
cache.


-Matej

On Nov 16, 2007 11:40 PM, mfs <fa...@gmail.com> wrote:
>
> Guys,
>
> I am yet bringing the same question again, regarding the SLCSS and the need
> to maintain it the older versions of the page on the disk or otherwise...and
> would really appreciate if some of my questions could be addressed here..
>
> Before i go into Second Level Cache..i would say that i still can comprehend
> the reason to store the latest version of a page (or the last accessed
> version) in the session, since a user can click the browser back button and
> access it (though by default this wouldnt happen and we would need to set
> the header to "no-store" so that a request is sent to the server instead of
> loading the last page from browser-cache)..or if we have a back button
> functionality explicitly implemented on our page...or yet otherwise if the
> user clicks the refresh button we can still utilize the last page-version..
>
> Coming to the Second Level Cache, i still find it hard to understand as to
> why and when would one come to the need of accessing the old serialized page
> versions (other than the latest) ? what would those use-cases be when would
> be want to access the earlier versions of a page ? Can someone point me some
> of those scenarios...
>
> Thanks in advance and Regards,
>
> Farhan.
>
>
>
>
>
> --
> View this message in context: http://www.nabble.com/Second-Level-Cache-tf4824369.html#a13803095
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Second Level Cache

[Eelco Hillenius <ee...@gmail.com>]

> hmmm..so correct me if its not the right understanding..i.e. the only time
> wicket would be fetching the older page versions is when a user hit the back
> button and clicks on a link (or submit a form) from that previous page, and
> with that whatever page-version those links/forms were linked to (which
> would be the original rendered page) wicket would load that page.

Yes.

> That means one (ideally) wouldn't code anything himself to refer to the old
> page versions lets say in the page to be rendered next, thats why i sort of
> was into thinking as to why would i refer to an older version, so its only
> the back button where this whole idea of version-ing comes in.

The only thing you might code yourself are explicit changes. Changes
in the component tree and some model (setModelObject specifically)
will be recorded automatically, but property changes for instance
won't be caught by Wicket. If you're not sure anything else triggers
the recording of a new version, you could consider making changes
explicit like for instance PageableListView#setCurrentPage does.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Second Level Cache

[mfs <fa...@gmail.com>]

hmmm..so correct me if its not the right understanding..i.e. the only time
wicket would be fetching the older page versions is when a user hit the back
button and clicks on a link (or submit a form) from that previous page, and
with that whatever page-version those links/forms were linked to (which
would be the original rendered page) wicket would load that page. 

That means one (ideally) wouldn't code anything himself to refer to the old
page versions lets say in the page to be rendered next, thats why i sort of
was into thinking as to why would i refer to an older version, so its only
the back button where this whole idea of version-ing comes in.

Farhan.



Eelco Hillenius wrote:
> 
>> Well i think it is required, at least as far as the browser back button
>> is
>> concerned (which is one of the features of wicket i.e. "back button
>> support"), unless otherwise as you said where one explicitly wants to
>> make a
>> call to the old versions
> 
> You don't need to do roundtrips right away. It would only generate
> load for nothing. The resurrection of old pages can be delayed until
> you actually do something with it.
> 
>>, but even with that i wonder how would one go about
>> maintaining the references to these older page versions (so as to access
>> it
>> at later pages)?
> 
> That's the responsibility of the session store. The number of saved
> pages is sufficiently large for normal use, and as it is configurable,
> you can go as wild as you like.
> 
>> and lets just say even we do explicitly maintain them
>> somewhere (e.g. in the session itself OR pass it from the previous
>> pages), i
>> think one wouldnt come to the need of referring the older versions of
>> their
>> components from within their application (except for the last couple of
>> pages).
> 
> Page versions are stored transparently. It is not something you should
> concerned about as a framework user. If a request comes in that can't
> be resolved to the current page, Wicket will ask the page store to get
> the older version. These older versions were stored using
> serialization, so you just roll back to an older snapshot of the
> component state.
> 
> Eelco
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Second-Level-Cache-tf4824369.html#a13816327
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Second Level Cache

[Eelco Hillenius <ee...@gmail.com>]

> Well i think it is required, at least as far as the browser back button is
> concerned (which is one of the features of wicket i.e. "back button
> support"), unless otherwise as you said where one explicitly wants to make a
> call to the old versions

You don't need to do roundtrips right away. It would only generate
load for nothing. The resurrection of old pages can be delayed until
you actually do something with it.

>, but even with that i wonder how would one go about
> maintaining the references to these older page versions (so as to access it
> at later pages)?

That's the responsibility of the session store. The number of saved
pages is sufficiently large for normal use, and as it is configurable,
you can go as wild as you like.

> and lets just say even we do explicitly maintain them
> somewhere (e.g. in the session itself OR pass it from the previous pages), i
> think one wouldnt come to the need of referring the older versions of their
> components from within their application (except for the last couple of
> pages).

Page versions are stored transparently. It is not something you should
concerned about as a framework user. If a request comes in that can't
be resolved to the current page, Wicket will ask the page store to get
the older version. These older versions were stored using
serialization, so you just roll back to an older snapshot of the
component state.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Second Level Cache

[mfs <fa...@gmail.com>]

Well i think it is required, at least as far as the browser back button is
concerned (which is one of the features of wicket i.e. "back button
support"), unless otherwise as you said where one explicitly wants to make a
call to the old versions, but even with that i wonder how would one go about
maintaining the references to these older page versions (so as to access it
at later pages)? and lets just say even we do explicitly maintain them
somewhere (e.g. in the session itself OR pass it from the previous pages), i
think one wouldnt come to the need of referring the older versions of their
components from within their application (except for the last couple of
pages).

Farhan.



Eelco Hillenius wrote:
> 
> On Nov 17, 2007 4:58 PM, mfs <fa...@gmail.com> wrote:
>>
>> So basically i meant setting "no-store" in your response header so that
>> the
>> browser doesnt load the page from its local-cache, and instead sends the
>> request to the server and let wicket load the last serialized page.
> 
> I don't think it needs that, as it doesn't have to do the actual
> reloading until you actually trigger a call back to that page (such as
> a link or form submit). And those call backs will have the version
> info in them.
> 
> Eelco
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Second-Level-Cache-tf4824369.html#a13815526
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Second Level Cache

[Eelco Hillenius <ee...@gmail.com>]

On Nov 17, 2007 4:58 PM, mfs <fa...@gmail.com> wrote:
>
> So basically i meant setting "no-store" in your response header so that the
> browser doesnt load the page from its local-cache, and instead sends the
> request to the server and let wicket load the last serialized page.

I don't think it needs that, as it doesn't have to do the actual
reloading until you actually trigger a call back to that page (such as
a link or form submit). And those call backs will have the version
info in them.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Second Level Cache

[mfs <fa...@gmail.com>]

So basically i meant setting "no-store" in your response header so that the
browser doesnt load the page from its local-cache, and instead sends the
request to the server and let wicket load the last serialized page.

Farhan.



Eelco Hillenius wrote:
> 
>> I understand that the browser back button doesnt really come in the above
>> context, but you agree to the fact that one has to do a no-store to
>> actually
>> LET wicket load the page from the SLC otherwise this back button support
>> by
>> wicket (which is considered to be one of the main features of it)
>> wouldn't
>> really come into play?
> 
> I don't understand what you mean here tbh. Wicket's default
> configuration handles the back button, and pages are loaded from
> DiskPageStore. If you use a 'no-store' (you mean an empty
> implementation of IPageStore with that, right?), you wouldn't have
> back button support as Wicket wouldn't be able to find any other page
> than the current one. You have to understand that SLCSS comes in two
> parts: the session store itself, which uses the HttpSession to store
> the current page (which is why it would be clustered if you'd use
> normal session clustering) and the page store, which exists to store
> older page versions.
> 
> Eelco
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Second-Level-Cache-tf4824369.html#a13815263
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Second Level Cache

[Eelco Hillenius <ee...@gmail.com>]

> I understand that the browser back button doesnt really come in the above
> context, but you agree to the fact that one has to do a no-store to actually
> LET wicket load the page from the SLC otherwise this back button support by
> wicket (which is considered to be one of the main features of it) wouldn't
> really come into play?

I don't understand what you mean here tbh. Wicket's default
configuration handles the back button, and pages are loaded from
DiskPageStore. If you use a 'no-store' (you mean an empty
implementation of IPageStore with that, right?), you wouldn't have
back button support as Wicket wouldn't be able to find any other page
than the current one. You have to understand that SLCSS comes in two
parts: the session store itself, which uses the HttpSession to store
the current page (which is why it would be clustered if you'd use
normal session clustering) and the page store, which exists to store
older page versions.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Second Level Cache

[mfs <fa...@gmail.com>]

So i guess one of the things i misunderstood earlier was that i assumed that
the pageMap maintains the latest page-instance/version (in the active
session) of all the different page-components, but as it turns out its just
the latest accessed page's instance which is kept in the session, and hence
just one active-page in session at one time, all other instances of
different page-components are serialized to the disk.

I understand that the browser back button doesnt really come in the above
context, but you agree to the fact that one has to do a no-store to actually
LET wicket load the page from the SLC otherwise this back button support by
wicket (which is considered to be one of the main features of it) wouldn't
really come into play?

Thanks again man..you guys are doing a great job..!

Farhan.





Johan Compagner wrote:
> 
> No it is a bit different
> the SLC is for back button support.
> The reason that we have the latest page in the session is because thats
> the
> live
> page where all the action is on. So that page is NOT used when the users
> hits the backbutton
> that page is only used when the users clicks a link or submits a button or
> triggers an ajax event.
> When the users hits the backbutton then the SLC comes into play and will
> reload that
> previous page from disk. If you do no-store that doesnt matter in that
> area (that only annoys users)
> because the page is read earlier from disk then when you don't have
> no-store
> (with no-store
> immediantly when the users hits the back, else only when a users does
> something on that page)
> 
> johan
> 
> 
> 
> On Nov 16, 2007 11:40 PM, mfs <fa...@gmail.com> wrote:
> 
>>
>> Guys,
>>
>> I am yet bringing the same question again, regarding the SLCSS and the
>> need
>> to maintain it the older versions of the page on the disk or
>> otherwise...and
>> would really appreciate if some of my questions could be addressed here..
>>
>> Before i go into Second Level Cache..i would say that i still can
>> comprehend
>> the reason to store the latest version of a page (or the last accessed
>> version) in the session, since a user can click the browser back button
>> and
>> access it (though by default this wouldnt happen and we would need to set
>> the header to "no-store" so that a request is sent to the server instead
>> of
>> loading the last page from browser-cache)..or if we have a back button
>> functionality explicitly implemented on our page...or yet otherwise if
>> the
>> user clicks the refresh button we can still utilize the last
>> page-version..
>>
>> Coming to the Second Level Cache, i still find it hard to understand as
>> to
>> why and when would one come to the need of accessing the old serialized
>> page
>> versions (other than the latest) ? what would those use-cases be when
>> would
>> be want to access the earlier versions of a page ? Can someone point me
>> some
>> of those scenarios...
>>
>> Thanks in advance and Regards,
>>
>> Farhan.
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Second-Level-Cache-tf4824369.html#a13803095
>> Sent from the Wicket - User mailing list archive at
>> Nabble.com<http://nabble.com/>
>> .
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/Second-Level-Cache-tf4824369.html#a13815164
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Second Level Cache

[Johan Compagner <jc...@gmail.com>]

No it is a bit different
the SLC is for back button support.
The reason that we have the latest page in the session is because thats the
live
page where all the action is on. So that page is NOT used when the users
hits the backbutton
that page is only used when the users clicks a link or submits a button or
triggers an ajax event.
When the users hits the backbutton then the SLC comes into play and will
reload that
previous page from disk. If you do no-store that doesnt matter in that
area (that only annoys users)
because the page is read earlier from disk then when you don't have no-store
(with no-store
immediantly when the users hits the back, else only when a users does
something on that page)

johan



On Nov 16, 2007 11:40 PM, mfs <fa...@gmail.com> wrote:

>
> Guys,
>
> I am yet bringing the same question again, regarding the SLCSS and the
> need
> to maintain it the older versions of the page on the disk or
> otherwise...and
> would really appreciate if some of my questions could be addressed here..
>
> Before i go into Second Level Cache..i would say that i still can
> comprehend
> the reason to store the latest version of a page (or the last accessed
> version) in the session, since a user can click the browser back button
> and
> access it (though by default this wouldnt happen and we would need to set
> the header to "no-store" so that a request is sent to the server instead
> of
> loading the last page from browser-cache)..or if we have a back button
> functionality explicitly implemented on our page...or yet otherwise if the
> user clicks the refresh button we can still utilize the last
> page-version..
>
> Coming to the Second Level Cache, i still find it hard to understand as to
> why and when would one come to the need of accessing the old serialized
> page
> versions (other than the latest) ? what would those use-cases be when
> would
> be want to access the earlier versions of a page ? Can someone point me
> some
> of those scenarios...
>
> Thanks in advance and Regards,
>
> Farhan.
>
>
>
>
>
> --
> View this message in context:
> http://www.nabble.com/Second-Level-Cache-tf4824369.html#a13803095
> Sent from the Wicket - User mailing list archive at Nabble.com<http://nabble.com/>
> .
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>