Stateful BSP Applications 
Stateful BSP Applications
A stateful BSP application is executed like a normal SAP transaction, – independent of all user interactions - in one single context (roll area). This means that data specified by the user during the application execution or data determined by the application itself is available potentially throughout the entire execution duration of the session.
Since the HTTP protocol itself operates in stateless mode and knows no implicit mechanism to assign independent requests to a common logical session, the BSP runtime uses
Session Cookies to group requests into one common session. The name of the cookie is sap-contextid, the validity area is restricted to the URL of the BSP application. This means that a BSP application can be executed within a browser only once at any one time. Different BSP applications can operate in parallel in the same browser. Multiple users/browsers can execute the same BSP application in parallel as often as required.Advantage
The main advantage of stateful BSP applications is that they are simple to program. As usual, you have access to data determined previously and reading or re-calculating data can often be omitted. For database-intensive applications, this can lead to considerably better system performance compared to a procedure where identical read operations have to be executed for every request.
Disadvantage
This significant advantage is at the same time however a disadvantage – the improved runtime is offset by a larger memory requirement. The number of possible parallel sessions in an SAP Web Application Server is restricted not least by the amount of available memory space. When this space is exhausted, no further sessions can be started and users cannot log on.
A further advantage is the fact that, unlike SAPGUI, Web browsers do not log off servers, that is, if users navigate in their Web browsers to a different Web site, the SAP Web Application Server is not be informed. Thus, an open session cannot be terminated and is retained in the application server until the context is released by the timeout mechanism. Since this can take some time, scarce resources are unnecessarily blocked in the application server.
Note that with stateful applications, the application status can be easily distinguished from the status users accept based on their interface. This can be caused by users navigating in the browser history or using the browser Back button - information that is not necessarily passed on to the server. So a user may navigate back to a Web site and the Web site sends the information again even though the application is expecting other requests. Measures are required in the application to deal with this.
In the next release, we plan to provide at least one detection mechanism.
See also:
Stateless BSP Applications Hybrid Forms Setting Stateful or Stateless Stateful or Stateless Programming?