This software-engineering-related article is a stub. You can help Wikipedia by adding missing information.

• v
• t
• e

This user page or section is undergoing significant expansion or restructuring. You are welcome to assist in its construction by editing it as well. If this user page has not been edited in several days, please remove this template. If you are actively editing this article or section, you can replace this template with {{in use|5 minutes}}. This page was last edited by Marcoscata (talk | contribs) 16 years ago. (Update timer)

The cloackroom pattern is a web programming technique that addresses the shortcomings of shared session-level objects in multi-tab browsers. By sharing the same session objects, different browser tabs that request the same operation from the server, but with different input parameters, are likely to end up with inconsistent results in certain circumstances. The cloackroom pattern addresses these potential inconsistencies by introducing and managing an artificial view-level context.

Common web applications are built around the principles of user sessions. Simply put, an HTTP conversation between a client and the server start when the client issues a request to the server, and ends when one of the following happens:

• the server satisfies the request
• the server replies with an error or a redirection
• a timeout occurs

When the user moves around the pages of a web application, each request is completely oblivious to any details about previous HTTP conversations between the same client and the same server. In a web application, server-side request-scoped objects exist only for the duration of the request, and therefore have no way to persist data in between requests.

A way to persist object state beyond the request scope is provided by the web server session. Roughly speaking, in an average web application requiring user login, a new session is usually created when the user first logs in to a website, and ends when the user either logs off the website or closes the web browser. Any server-side object associated with the user session is then destroyed at the end of the user session.

Single-view browsers (the ones without tabbed browsing) have worked well with this architecture for years, simply because it was easy to establish a one-to-one relationship between the browser application and the server session: opening a new browser window would create a new session on the server, and each "view" would live completely independently from the others.

With the advent of multi-tab browsers, this architecture has started to show some shortcomings, mainly due to the fact that multiple tabs in the same browser window usually share the same server session. This breaks the one-to-one relationship between views and sessions, translating into inconsistent user experience and other problems.

Inconsistenceis are perhaps best explained with an example.

Let's say a user is browsing a hypothetical yellow pages application. The user decides to search for a local florist, so she types "florist" in the search box, hits the submit button, and the server replies with a list of local florists and their telephone numbers.

Now let's say the user wants to search for local libraries without losing the current list of local florists just retrieved. Using a single-view browser, the user will have to open a new browser window, type "library" in the search box and click the submit button, after which the server will reply with a list of local libraries and their telephone numbers. The two windows would be completely independent from one another, so the user can always go back to the first window (the one with the florists' data) and find the original results.

Using a multi-tab browser, the user will probably open a new tab in the same browser window and perform the library search in that tab. However, upon returning to the first tab (the one with the florists' data) and hitting the refresh button, the server will probably reply with the libraries' data instead.

View-Level Caching