MCS maintains state in memory in the case of fragments and external CSS stylesheets, and in sessions in the case of forms. MCS therefore requires that 'sticky' sessions are enabled if it is to work correctly in a multiple-machine environment.
Session information is not serialized, so it will not be moved from one machine to another, even if the application server can do that automatically.
Information about which fragments from which layouts are active, as well as which shard from each visible pane is visible, is retained in memory. The state is selected by a request parameter. The mapping from the parameter value to the state is generated on demand, so the same parameter value is likely to map to different state on different machines. This means that fragment links for a page must be sent back to the machine that produced the page; otherwise the resulting page will not contain the correct set of fragments.
Form specific state is needed in order to fix up differences between how different markup languages (mainly HTML and WML) submit the values for the same type of field. This normalization of request parameters is performed automatically by MCS, and the normalized parameters are available through methods on the MarinerRequestContext. MCS retains the state in session of values which were provided in the form, but which is not passed to the page that handles the form.
Failing to send the form submission back to the same machine that generated the form may cause corruption of the parameters.
The HTML / WML issues are as follows.
xfaction and xforms:submit: HTML uses the value of an <input type="submit"> as the caption to display. As captions can be translated it could vary from one user to another but the page that processes the form submission should not have to deal with the translated captions so MCS does it automatically. WML does not have this problem as the generated markup explicitly submits the value of the action, not the caption/label.
xfmuselect and xforms:select: WML submits multiple values using a single request parameter, and separates each value with a ';'. HTML on the other hand submits it as separate instances of the same parameter. MCS automatically converts the multiple value WML parameter into the HTML format but in order to do that it needs to know the type of the field.
Page authors can specify whether or not MCS should use sessions when processing forms. In stateful mode, the form-related information will be retained in the session. Note that in such case a form submission will fail if the session has expired, and that 'sticky' sessions need to be enabled in a multiple-machine environment. In stateless mode, MCS does not use sessions when processing forms, i.e. no information about the form will be maintained by MCS between form rendering and form submission. Please note that using stateless mode will increase the size of pages containing forms.
The mcs:form-processing-options meta property allows page authors to specify the form processing options on a per-page basis. This property supports two values: 'stateless' and 'stateful'. The default value of 'stateful' indicates that MCS needs to use sessions when processing forms. 'stateless' means that MCS must not use sessions when processing form-related information. This meta property is associated with the document and therefore it is only valid within the head section of the document and must have no about attribute.
The mcs:form-processing-options meta property overrides the default mode specified by the form-processing-options attribute of the xdime element in the mcs-config.xml configuration file. Refer to the topic entitled xdime for further information.
Fragmented forms are always stateful.
A fragmented form is represented as multiple forms to the target device. The submitted values must be collated, so that when the form has been completed, they can be passed to the processing page as a complete set. Also, as HTML does not allow multiple targets for submitting a single form it is necessary for all the form submissions to be dispatched to a servlet that will then redirect the request to either the source page to generate the next/previous fragment, or the processing page to handle the whole form. This information is retained in the session.
Failing to send the form fragment submissions back to the same machine that generated the form fragments may cause corruption of the parameters and/or incorrect navigation.
MCS generates optimized CSS for each page, and ideally this should be provided as part of the page. However, some devices do not support internal CSS, or have restrictive limits on the size of the internal CSS. So they need to be stored externally to the page and referenced using a URL. This CSS is stored in memory and accessed using a secure key to prevent clashes.
Failing to send the request for the external CSS back to the same machine that generated the referencing page will usually cause no styling to be visible.