Checkpointing Thin-Bean State

To support bookmarks in an HTML-client application that incorporates BI Beans, you must store state information so that it exists beyond the current browser session. You can store state information in the URL, but state information, especially for the query, can quickly grow beyond the boundaries of the URL. When this happens, the URL is truncated, and the loss of information makes it impossible to display a page as it appeared when the bookmark was set.

To prevent the growth of state information beyond the boundaries of the URL, you use checkpointing. Checkpointing allows you to keep track of more than one set of state changes. State objects that you store in the BI Beans Catalog store strings that describe changes between the original call to setBaseState method and the call to getState that produced the string. State strings that you store in the URL describe changes between the last checkpoint (when you saved the state in the Catalog by calling getState and then started keeping track of checkpoint changes by calling checkpointState) and the call to getCheckpointState that produced the string.

Saving thin-bean state strings in the BI Beans Catalog

When you save state strings in the BI Beans Catalog, you have the complete state of the thin bean in three places:

State manager for saving state strings

When you save state strings in the BI Beans Catalog, you use the BIStateManager to get MutableState objects in which to store state strings. The MutableState interface extends the State interface; both of these interfaces are in the oracle.cabo.servlet.state package. To store a State object in the BI Beans Catalog, you call BIStateManager.saveState, passing the State object. The BIStateManager is in the oracle.dss.thin.state package.

Getting state information

When your application receives an HTTP request, you must extract state information in order to set in on the thin beans in your application. You must extract the following information:

As always, set the state of each thin bean before you handle any thin-bean events that are in the URL.

Storing state information

When you store state strings in the BI Beans Catalog, you do not want to store a new State object for every HTTP request. This would result in numerous State objects, and continually accessing the BI Beans Catalog degrades the performance of your application. You really only need to store State objects when the URL is nearing its size limit.

Each BI Beans thin bean generates events, and these events and their paramaters are documented in the javadoc. Browsers use escape characters when they construct the URL from the hidden form fields, where they are stored. If you account for the escaped characters, then you can determine the number of characters that will be placed on the URL for the state of the thin beans in a page. You can then determine the number of bytes, based on the character set you are using. Add any parameters that your application places on the URL, and subtract this total from the URL limit for any browsers that your application needs to support.

Reducing the size of the URL

To reduce the size of the URL, take the following steps:

  1. Call getState on the thin bean to retrieve its state string. Instead of placing the state in the URL, store it in a MutableState object that you get from the BIStateManager.

  2. Call BIStateManager.saveState to save the MutableState in the BI Beans Catalog.

  3. Call the checkpointState method of the thin bean to clear the checkpoint state and to start keeping track of changes.

  4. Call getCheckpointState to get the checkpoint state, and store it, with the ID of the MutableState and the location of the thin bean, in the URL.

Managing State in an HTML-Client Application
Getting Thin-Bean State
Setting Thin-Bean State
BI Beans Request-Handling Sequence