RE: sanity check request for fix regarding the dreaded PageExpiredException
Thanks Igor and Alex for the feedback. It is very much appreciated! Joe -Original Message- From: Alex Rass [mailto:a...@itbsllc.com] Sent: Monday, September 27, 2010 11:47 AM To: users@wicket.apache.org Subject: RE: sanity check request for fix regarding the dreaded PageExpiredException Igor's is 100% right Plus you are forgetting that if you use the default page url constructor - it goes by interface number which will/may change after a redeploy. So your lost url bullet can be fixed if you use some url creation strategy that solidifies in it enough of the path that you can recreate your last page location Then maybe add the important parts of the user state to the same strategy and you are there. There are a bunch of examples on how to do this, but I am feeling too lazy to go search ;) - Alex -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Monday, September 27, 2010 11:28 AM To: users@wicket.apache.org Subject: Re: sanity check request for fix regarding the dreaded PageExpiredException you can try it and see if it works for your particular usecases. there may still be some edges that will break, like links you actually want to run against an older version of the page because they depend on the component hierarchy that existed then, etc. -igor On Fri, Sep 24, 2010 at 7:56 AM, Joe Hudson joe.hud...@clear2pay.com wrote: Hi, I know there have been several existing topics around this issue (http://apache-wicket.1842946.n4.nabble.com/debugging-PageExpiredExceptions- td1882040.html) for example. The reason that I am asking for a sanity check is because I plan to use an alternative approach to solving this issue and would like feedback to make sure there isn't a reason I shouldn't be doing this. The common approach is to catch the exception and return a new instance of the requested page. This seems to have some key drawbacks IMHO: 1) this only works with bookmarkable links 2) you lose any modifications to the model that happened after the page was originally loaded but before the exception occured 3) any data on the client may potentially be out of sync with the server state if not updated by the request that caused the exception (because the new page was loaded but that client representation is still a picture of the previous page with the previous model). Although this would be resolved by a form submit behavior - you would still have problems in the exceptional cases where the model is updated individually by input field ajax change events. It seems that the page version number is only necessary for a stateless application and in an ajax-oriented application you would always want to work with the latest page version. We seem to hit these issues when multiple ajax requests that target a particular page happen concurrently because the page version is incremented when the initial ajax request is made but all other ajax requests that are initiated before the initial ajax request response reference a now outdated page version number. So, after all that background - do you think this is a valid fix for an ajax-oriented application: Override the default SecondLevelCachePageMap and as long as the requested page id matches the page id of getLastPage() just return the last page. Your thoughts would be appreciated and sorry for the long email but I wanted to provide background to make sure that the fix was valid for my particular solution (because I know the fix would not be appropriate for a stateless application). Thanks Joe Hudson - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: sanity check request for fix regarding the dreaded PageExpiredException
you can try it and see if it works for your particular usecases. there may still be some edges that will break, like links you actually want to run against an older version of the page because they depend on the component hierarchy that existed then, etc. -igor On Fri, Sep 24, 2010 at 7:56 AM, Joe Hudson joe.hud...@clear2pay.com wrote: Hi, I know there have been several existing topics around this issue (http://apache-wicket.1842946.n4.nabble.com/debugging-PageExpiredExceptions-td1882040.html) for example. The reason that I am asking for a sanity check is because I plan to use an alternative approach to solving this issue and would like feedback to make sure there isn't a reason I shouldn't be doing this. The common approach is to catch the exception and return a new instance of the requested page. This seems to have some key drawbacks IMHO: 1) this only works with bookmarkable links 2) you lose any modifications to the model that happened after the page was originally loaded but before the exception occured 3) any data on the client may potentially be out of sync with the server state if not updated by the request that caused the exception (because the new page was loaded but that client representation is still a picture of the previous page with the previous model). Although this would be resolved by a form submit behavior - you would still have problems in the exceptional cases where the model is updated individually by input field ajax change events. It seems that the page version number is only necessary for a stateless application and in an ajax-oriented application you would always want to work with the latest page version. We seem to hit these issues when multiple ajax requests that target a particular page happen concurrently because the page version is incremented when the initial ajax request is made but all other ajax requests that are initiated before the initial ajax request response reference a now outdated page version number. So, after all that background - do you think this is a valid fix for an ajax-oriented application: Override the default SecondLevelCachePageMap and as long as the requested page id matches the page id of getLastPage() just return the last page. Your thoughts would be appreciated and sorry for the long email but I wanted to provide background to make sure that the fix was valid for my particular solution (because I know the fix would not be appropriate for a stateless application). Thanks Joe Hudson - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: sanity check request for fix regarding the dreaded PageExpiredException
Igor's is 100% right Plus you are forgetting that if you use the default page url constructor - it goes by interface number which will/may change after a redeploy. So your lost url bullet can be fixed if you use some url creation strategy that solidifies in it enough of the path that you can recreate your last page location Then maybe add the important parts of the user state to the same strategy and you are there. There are a bunch of examples on how to do this, but I am feeling too lazy to go search ;) - Alex -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Monday, September 27, 2010 11:28 AM To: users@wicket.apache.org Subject: Re: sanity check request for fix regarding the dreaded PageExpiredException you can try it and see if it works for your particular usecases. there may still be some edges that will break, like links you actually want to run against an older version of the page because they depend on the component hierarchy that existed then, etc. -igor On Fri, Sep 24, 2010 at 7:56 AM, Joe Hudson joe.hud...@clear2pay.com wrote: Hi, I know there have been several existing topics around this issue (http://apache-wicket.1842946.n4.nabble.com/debugging-PageExpiredExceptions- td1882040.html) for example. The reason that I am asking for a sanity check is because I plan to use an alternative approach to solving this issue and would like feedback to make sure there isn't a reason I shouldn't be doing this. The common approach is to catch the exception and return a new instance of the requested page. This seems to have some key drawbacks IMHO: 1) this only works with bookmarkable links 2) you lose any modifications to the model that happened after the page was originally loaded but before the exception occured 3) any data on the client may potentially be out of sync with the server state if not updated by the request that caused the exception (because the new page was loaded but that client representation is still a picture of the previous page with the previous model). Although this would be resolved by a form submit behavior - you would still have problems in the exceptional cases where the model is updated individually by input field ajax change events. It seems that the page version number is only necessary for a stateless application and in an ajax-oriented application you would always want to work with the latest page version. We seem to hit these issues when multiple ajax requests that target a particular page happen concurrently because the page version is incremented when the initial ajax request is made but all other ajax requests that are initiated before the initial ajax request response reference a now outdated page version number. So, after all that background - do you think this is a valid fix for an ajax-oriented application: Override the default SecondLevelCachePageMap and as long as the requested page id matches the page id of getLastPage() just return the last page. Your thoughts would be appreciated and sorry for the long email but I wanted to provide background to make sure that the fix was valid for my particular solution (because I know the fix would not be appropriate for a stateless application). Thanks Joe Hudson - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
