You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by "J.-F. Rompre" <jr...@gmail.com> on 2009/06/07 19:16:18 UTC
Stateful vs stateless requests and navigation
Hello all,
I have a question regarding the way wicket treats session- versus stateless-
requests when
accessed outside the app. navigation (back/forward buttons, "BFBs").
Ideally my navigation 'robustness' goal is for the user to be able to use
BFBs to view pages accordingly, but without reversing changes to the
shopping cart, or displaying inaccuracies (such as updating the cart,
hitting the BB and looking at the cached page with old cart content).
SETUP A
So I tried setting the response headers to 'no-cache','no-store' as
prescribed in other threads - that forces each request to go to the server
and fixed the accuracy problem. - cart contents were then always accurate.
However all stateless- requests such as paging URLs got rejected with 'Page
expired', even though the session is obviously live (versions keep getting
incremented
using app. navigation for stateful requests, shopping cart is OK, etc..).
SETUP B
Next I tried URLHybridCodingStrategy combined with the 'no-cache',
'no-store' header config. and that removed the 'Page expired' problem.
However, I still can't access the previous screen when it was accessed with
a stateful request such as pagination: instead, the user is sent back to the
beginning of the pageable list.
Also, with my current setup B above, I am expecting page instances to be
reused when accessed within a session: however new page instances are
created for each single request except for pagination requests - those go to
the latest version, I assume.
So my question is two-fold:
1) Does setting no-cache and/or no-store in the header cause the page map to
keep only the current version, or older verions to be inaccessible via the
request URL? I know that 'Page Expired' can have other causes e.g.
serialization issues, but if that was the case here then setup B would have
failed as well? Unless the problem exists in both cases both is 'skipped
over' by the HybridUrlCodingStrategy?
2) What drives the decision to reuse page instances, other than
non-bookmarkability?
Any comment or pointer to existing documentation is greatly appreciated.
Thanks,
JF
Re: Stateful vs stateless requests and navigation
Posted by "J.-F. Rompre" <jr...@gmail.com>.
Thank you Igor - I hadn't turned the logs on. Making the domain serializable
fixed the issue. I didn't think this would happen because I am using
LoadableDetachable models passed to a list view - probably serializing to
produce list items - will see if individual items can be fetched from cache.
Sorry for any inconvenience..
JF
On Mon, Jun 8, 2009 at 12:26 PM, Igor Vaynberg <ig...@gmail.com>wrote:
> On Sun, Jun 7, 2009 at 10:16 AM, J.-F. Rompre<jr...@gmail.com> wrote:
> > SETUP A
> > So I tried setting the response headers to 'no-cache','no-store' as
> > prescribed in other threads - that forces each request to go to the
> server
> > and fixed the accuracy problem. - cart contents were then always
> accurate.
> > However all stateless- requests such as paging URLs got rejected with
> 'Page
> > expired', even though the session is obviously live (versions keep
> getting
> > incremented
> > using app. navigation for stateful requests, shopping cart is OK, etc..).
>
> this should work without problems. are you sure there are no errors in
> your logs? the page should not be expired. feel free to create a
> quickstart that reproduces the problem and attach it to a jira issue.
>
> -igor
>
> >
> > SETUP B
> > Next I tried URLHybridCodingStrategy combined with the 'no-cache',
> > 'no-store' header config. and that removed the 'Page expired' problem.
> > However, I still can't access the previous screen when it was accessed
> with
> > a stateful request such as pagination: instead, the user is sent back to
> the
> > beginning of the pageable list.
> >
> >
> > Also, with my current setup B above, I am expecting page instances to be
> > reused when accessed within a session: however new page instances are
> > created for each single request except for pagination requests - those go
> to
> > the latest version, I assume.
> >
> >
> > So my question is two-fold:
> >
> > 1) Does setting no-cache and/or no-store in the header cause the page map
> to
> > keep only the current version, or older verions to be inaccessible via
> the
> > request URL? I know that 'Page Expired' can have other causes e.g.
> > serialization issues, but if that was the case here then setup B would
> have
> > failed as well? Unless the problem exists in both cases both is 'skipped
> > over' by the HybridUrlCodingStrategy?
> >
> > 2) What drives the decision to reuse page instances, other than
> > non-bookmarkability?
> >
> > Any comment or pointer to existing documentation is greatly appreciated.
> >
> > Thanks,
> >
> > JF
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
JF
"If you want the rainbow, you gotta put up with the rain." -- Steven Wright
Re: Stateful vs stateless requests and navigation
Posted by Igor Vaynberg <ig...@gmail.com>.
On Sun, Jun 7, 2009 at 10:16 AM, J.-F. Rompre<jr...@gmail.com> wrote:
> SETUP A
> So I tried setting the response headers to 'no-cache','no-store' as
> prescribed in other threads - that forces each request to go to the server
> and fixed the accuracy problem. - cart contents were then always accurate.
> However all stateless- requests such as paging URLs got rejected with 'Page
> expired', even though the session is obviously live (versions keep getting
> incremented
> using app. navigation for stateful requests, shopping cart is OK, etc..).
this should work without problems. are you sure there are no errors in
your logs? the page should not be expired. feel free to create a
quickstart that reproduces the problem and attach it to a jira issue.
-igor
>
> SETUP B
> Next I tried URLHybridCodingStrategy combined with the 'no-cache',
> 'no-store' header config. and that removed the 'Page expired' problem.
> However, I still can't access the previous screen when it was accessed with
> a stateful request such as pagination: instead, the user is sent back to the
> beginning of the pageable list.
>
>
> Also, with my current setup B above, I am expecting page instances to be
> reused when accessed within a session: however new page instances are
> created for each single request except for pagination requests - those go to
> the latest version, I assume.
>
>
> So my question is two-fold:
>
> 1) Does setting no-cache and/or no-store in the header cause the page map to
> keep only the current version, or older verions to be inaccessible via the
> request URL? I know that 'Page Expired' can have other causes e.g.
> serialization issues, but if that was the case here then setup B would have
> failed as well? Unless the problem exists in both cases both is 'skipped
> over' by the HybridUrlCodingStrategy?
>
> 2) What drives the decision to reuse page instances, other than
> non-bookmarkability?
>
> Any comment or pointer to existing documentation is greatly appreciated.
>
> Thanks,
>
> JF
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org