It can be very time-consuming and use a lot of resources to rebuild a processor that was stored without finishing its flow each time a user sends a request to the server. Each time the toolkit receives one of these requests, it instantiates the processor using the processor externalizer and then modifies the instance with the information stored in the session context to make this instance exactly the same as the processor that the user left, including the same state, attribute values, and context. The toolkit also instantiates the processor context when instantiating the processor with the processor externalizer. This becomes expensive in terms of performance if the context contains large amounts of data, and it is inefficient because the processor context is replaced by the one stored in the session context. The HTML processors cache helps relieve this situation by allowing the toolkit to use the cached processor instead of rebuilding it. Note that the cache is only available for the session. For example, if the flow processor named myProc is in use by user1, it will exist in the cache while this user is navigating. If user2 runs a new instance of myProc, the toolkit creates a new entry in the cache for myProc instead of using the existing one.

As long as the cache is enabled (See Configuring the HTML Channel), the toolkit stores the flow processor instances in the cache whenever a page is displayed, and deletes the processor instances from cache when they are recovered by the user. When the processor attains its final state, the toolkit does not store it in the cache. Processors that do not reach a final state are kept in cache and the application must clean up these instances. For example, each time a page is displayed for user1, the toolkit stores myProc in the cache, and each time user1 sends a request from the browser, the toolkit restores the instance of myProc from the cache and then removes it from the cache. The same process occurs for user2. When user1's processor attains its final state, the toolkit does not store myProc in the cache, thus preventing a memory leak. If a page is displayed to user2, the toolkit stores myProc in the cache. If user2 then stops the process (by closing the browser for example), user2's instance of myProc remains in the cache. If user3 runs a new instance of myProc, the toolkit does not use the myProc stored in the cache. Instead, the toolkit creates a myProc instance and eventually stores it in the cache. This means that there will be two instances of myProc stored in the cache but the toolkit will only reuse one of them. The application must clean up the cache by removing user2's instance of myProc.