Roughly speaking, every page or document sent from a web server to a browser is the result of the same processing sequence. For our purposes a document is one page in an application.
The essentially stateless nature of the web presents problems for the application developer who wishes to retain state between different pages in their application. From the point of view of the user, the state of the application at the server is represented by the page that they see in their browser window(s). When they enter values and press submit buttons on their page they (quite reasonably) expect the application on the web server to process their request and return the next page in the application.
The point of view of the web application developer is very different. At the server side the application must be able to receive a request from one browser, process it and send the next application page back to that browser. Before seeing the next request from the same browser, another browser may request a different page from the application. The web application even has to deal with multiple browsers simultaneously accessing different pages in the application. All of this while maintaining the illusion for the end user that they are running their own copy of the application.
Even when you only have a single machine running Apache, there are multiple Apache processes on that machine that are receiving and processing browser requests. This means that there is no guarantee that the same process that received the last request from a particular browser will receive the next request from that browser. If your application requires some state to be retained between pages, there has to be a way for that state to migrate between different Apache processes. If you are using more than one machine to process requests, then you need some way for the application state to move between machines.
There are essentially three approaches to solving the state propagation problem.
Assuming that your application is non-trivial, the second approach (state held by the browser) is the easiest to implement.
If you are building a financial application, you will probably feel more comfortable with the third approach. This has the advantage of hiding implementation details of your application from prying eyes.
All three approaches are supported (in one way or another) by Albatross.
In all Albatross applications there are two important objects that determine how browser requests are processed; the application object, and the execution context object. The application is a potentially long lived object that provides generic services for multiple browser requests. A new execution context is created to process each browser request.
One of the things that the application and execution context do is cooperate to provide session functionality. The execution context is the object where session data is created and manipulated, but the application is usually responsible to loading and saving the session. This allows the application to maintain a long lived connection with a server if necessary.