Stateless Web Dynpro Applications
Java Web Dynpro applications running in stateless mode do not keep significant session state on the application server in between request processing. Instead, the Web Dynpro runtime can read and write the URL fragment part for session data storage on client side. Furthermore, some externalized session state can be hidden within the page. During runtime of a Web Dynpro application, a switch between stateless and stateful execution is supported. While the application is running statelessly, context menus and pending user input are allowed. The stateless mode is provided for standalone Web Dynpro applications, as well as for applications integrated into the Portal.
- Increased scalability: More users can be served by the same machine with respect to memory considerations
- Keeping URLs as bookmarks or favorites: User and time independent usage of the application in exactly the same state
- Independent state model: Applications programmed to run in stateless mode can also run in a stateful mode lateron
- Switches between stateless and stateful mode supported
| API | Method | Usage |
|---|---|---|
|
IWDComponent |
boolean isStatelessOK()
|
Provides information whether the component instance supports the stateless execution model |
|
|
void setStatelessOK(boolean ok) |
|
|
|
String getState()
|
Defines string representation of session state |
|
|
void setState(String state) |
Represents the current state of this component; During startup, it can be used to retrieve the previous state. Later on, it can be used to determine the new state. This kind of session state will be kept invisibly on the client side, hidden somewhere within the page |
|
IWDApplication |
String getURLFragment()
|
Defines string representation of URL fragment |
|
|
void setURLFragment(String fragment) |
Represents the current fragment part of the application's URL; can be used to include session state visibly within the URL |
Initial Request
Before the initial request is completely processed, in wdDoPostProcessing() at the latest, each involved component instance sets the statelessOK flag and updates its state property or the application's urlFragment property as appropriate. Definition of string representation of its session state is done by application developers.
The framework checks the statelessOK flag for all existing component instances at the end of request processing and decides if stateless execution is allowed. If so, it sends the hidden session state of all components to the client and ends the application after the response has been sent. The fragment part of the application's URL is also updated, regardless of stateless execution.
Follow-up Request
During the application's startup for a follow-up request, information about the previous state property can be retrieved for each component and be used to restore its session state. The fragment part of the application's URL is also available. It is the application's responsibility to completely restore the appropriate session state, including component creation, navigation, UI tree modification, and data retrieval.
During the second run of the phase loop, a normal request processing takes place. I.e. the application reacts to data changes and events from the client in the same way a stateful Web Dynpro application would do. Before the request is completely processed, the same properties have to be updated as in the initial request. Due to the stateless execution, the statelessOK flag has to be set each time.
Final Request
When the application is terminated, the framework doesn't include a hidden session state within the final response. Indeed, the fragment part of the application's URL is updated one last time.