HTML toolkit applications usually manage both the presentation and the business logic through HTML flow processors. The HTML flow processors are asynchronous processors, which means that their execution can stop before the processor has reached a final state. If this occurs, the execution can resume from the point where it was stopped. For example, when an HTML flow processor reaches a page state, its flow execution stops and the control passes to the HtmlRequestHandler. The HtmlRequestHandler passes the request to the HtmlPresentationHandler, which runs and displays the JSP. The toolkit must store information about the flow processor, because the user might send another request to the processor, expecting to find the processor in the same state as it was before the flow execution stopped.

To store the information needed to rebuild the processor, including the processor's context, the session context keeps a table of processors. The following is the toolkit information stored in the session context (the bold fields are storing the processors table and the contexts table):

The following diagram shows a context and its entry in the session table, as well as an HTML processor and context information:

The processor contexts remain unchained while the flow is on the user side. When the user sends a request to the HTML processor, the toolkit rebuilds the processor instance, attaches the processor context to it, and chains the processor context to the session context. Additionally, the toolkit removes the processor and context from the session context and does not store the HTML processor and context in the session context until the processor again reaches a page or subFlow state.