Kbase P10112: ADM2: Differences between AppServer stateless, state-reset and state-aware with SDOs
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
3/31/2008 |
|
Status: Verified
GOAL:
ADM2: Differences between AppServer stateless, state-reset and state-aware with SDOs
FIX:
AppServer Session Operating Modes and SmartDataObjects (from documentation)
In a distributed application, a SmartDataObject inherits its operating mode state-aware, stateless, or state-reset from the AppServer that it uses to access its database. (This is the default behavior; you need not configure the SmartDataObject specially for this to happen.)
These three modes operate as follows:
· In state-aware mode, a SmartDataObject connects to an AppServer session and binds it for the entire length of the SmartDataObject's client connection. At the end of the connection, the context (state) of the AppServer session remains and can be used by the next connection to that session. In this mode, it is unnecessary for a new connection to the AppServer session to re-establish context; however, it might be difficult to design a system in which each user can benefit from the context left by the previous user.
· In stateless mode, a SmartDataObject connects to an AppServer session but binds it only briefly to do the following:
- Re-establish the context of the AppServer session at the end of its last request
- Make a request
- Save the context for the next request
Between requests, nothing is bound. In this mode, each individual AppServer request might take slightly longer, but many clients can share fewer AppServer sessions with minimal performance degradation.
· In state-reset mode, the AppServer session's state is reset to the initial state after each connection. This is the state it is in immediately after the AppServer agent is started and after all startup parameters
are processed. This mode is particularly useful for applications that do not use SmartDataObjects.
In some cases, you might want a SmartDataObject to run in a state-aware mode even though the AppServer is running in stateless mode. For example, a SmartDataObject might have a query that is so complex that the overhead of re-establishing it at every use degrades performance. To request state-aware mode explicitly, you set the Force to Stateful Operating Mode instance property in the SmartDataObject's Instance Property dialog box. This property causes the SmartDataObject to run in state-aware mode even though AppServer session is running in stateless mode.
NOTE: A SmartDataObject executes exactly the same regardless of its operating mode.