Author: mgrigorov Date: Fri Dec 31 12:32:50 2010 New Revision: 1054104 URL: http://svn.apache.org/viewvc?rev=1054104&view=rev Log: WICKET-1973 Messages lost upon session failover with redirect_to_buffer
Add a note about REDIRECT_TO_ strategies and session failover. Modified: wicket/trunk/wicket-core/src/main/java/org/apache/wicket/settings/IRequestCycleSettings.java Modified: wicket/trunk/wicket-core/src/main/java/org/apache/wicket/settings/IRequestCycleSettings.java URL: http://svn.apache.org/viewvc/wicket/trunk/wicket-core/src/main/java/org/apache/wicket/settings/IRequestCycleSettings.java?rev=1054104&r1=1054103&r2=1054104&view=diff ============================================================================== --- wicket/trunk/wicket-core/src/main/java/org/apache/wicket/settings/IRequestCycleSettings.java (original) +++ wicket/trunk/wicket-core/src/main/java/org/apache/wicket/settings/IRequestCycleSettings.java Fri Dec 31 12:32:50 2010 @@ -36,9 +36,10 @@ import org.apache.wicket.util.time.Durat * <i>renderStrategy </i>- Sets in what way the render part of a request is handled. Basically, * there are two different options: * <ul> - * <li>Direct, ApplicationSettings.ONE_PASS_RENDER. Everything is handled in one physical request. - * This is efficient, and is the best option if you want to do sophisticated clustering. It does not - * however, shield you from what is commonly known as the <i>Double submit problem </i></li> + * <li>Direct, IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER. Everything is handled in one + * physical request. This is efficient, and is the best option if you want to do sophisticated + * clustering. It does not however, shield you from what is commonly known as the <i>Double submit + * problem </i></li> * <li>Using a redirect. This follows the pattern <a * href="http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost" >as described at the * serverside </a> and that is commonly known as Redirect after post. Wicket takes it one step @@ -46,20 +47,26 @@ import org.apache.wicket.util.time.Durat * double submit problem, but also the IRequestListener handlers (that could be e.g. a link that * deletes a row). With this pattern, you have two options to choose from: * <ul> - * <li>ApplicationSettings.REDIRECT_TO_RENDER. This option first handles the 'action' part of the - * request, which is either page construction (bookmarkable pages or the home page) or calling a - * IRequestListener handler, such as Link.onClick. When that part is done, a redirect is issued to - * the render part, which does all the rendering of the page and its components. <strong>Be aware - * </strong> that this may mean, depending on whether you access any models in the action part of - * the request, that attachment and detachment of some models is done twice for a request.</li> - * <li>ApplicationSettings.REDIRECT_TO_BUFFER. This option handles both the action- and the render - * part of the request in one physical request, but instead of streaming the result to the browser - * directly, it is kept in memory, and a redirect is issue to get this buffered result (after which - * it is immediately removed). This option currently is the default render strategy, as it shields - * you from the double submit problem, while being more efficient and less error prone regarding to - * detachable models.</li> + * <li>IRequestCycleSettings.RenderStrategy.REDIRECT_TO_RENDER. This option first handles the + * 'action' part of the request, which is either page construction (bookmarkable pages or the home + * page) or calling a IRequestListener handler, such as Link.onClick. When that part is done, a + * redirect is issued to the render part, which does all the rendering of the page and its + * components. <strong>Be aware </strong> that this may mean, depending on whether you access any + * models in the action part of the request, that attachment and detachment of some models is done + * twice for a request.</li> + * <li>IRequestCycleSettings.RenderStrategy.REDIRECT_TO_BUFFER. This option handles both the action- + * and the render part of the request in one physical request, but instead of streaming the result + * to the browser directly, it is kept in memory, and a redirect is issue to get this buffered + * result (after which it is immediately removed). This option currently is the default render + * strategy, as it shields you from the double submit problem, while being more efficient and less + * error prone regarding to detachable models.</li> * </ul> - * </li> + * Note: In rare cases the strategies involving redirect may lose session data! For example: if + * after the first phase of the strategy the server node fails without having the chance to + * replicate the session then the second phase will be executed on another node and the whole + * process will be restarted and thus anything stored in the first phase will be lost with the + * failure of the server node. For similar reasons it is recommended to use sticky sessions when + * using redirect strategies.</li> * </ul> * * <p> @@ -163,16 +170,20 @@ public interface IRequestCycleSettings /** * In order to do proper form parameter encoding it is important that the response and the * subsequent request stipulate a common character encoding. - * + * * possible form encodings and their problems: - * + * * <ul> - * <li><a href="http://www.crazysquirrel.com/computing/general/form-encoding.jspx">application/x-www-form-urlencoded</a></li> - * <li><a href="http://stackoverflow.com/questions/546365/utf-8-text-is-garbled-when-form-is-posted-as-multipart-form-data">multipart/form-data</a></li> + * <li><a + * href="http://www.crazysquirrel.com/computing/general/form-encoding.jspx">application/x- + * www-form-urlencoded</a></li> + * <li><a href= + * "http://stackoverflow.com/questions/546365/utf-8-text-is-garbled-when-form-is-posted-as-multipart-form-data" + * >multipart/form-data</a></li> * </ul> - * + * * wicket now uses multipart/form-data for it's forms. - * + * * @return The request and response encoding */ String getResponseRequestEncoding();