Figure 1: Sessions allow state to be stored across multiple requests.
Sessions provide the ability to store state across multiple requests to a data service resource. In other words, when the data service resource processes an activity described in one perform document, that activity may interact with a session and store some state. Then an activity specified in a subsequent perform document may interact with the same session to read, update or remove that state. The objects used to store state are known as session attributes. When a request interacts with a session, it is said to join that session. A session has a finite life-time after which it expires. It can only be joined and used for storing and accessing state during its life-time.
Figure 1 shows two perform document requests joining the same session. An activity within the first stores some state in a session attribute, which an activity from the second then accesses and updates. Storing state in this way is important because it allows a context to be created for operations that are spread across related requests. For example, a session could be used to manage a transaction described in three sequential requests. Each request would join the same session, storing, accessing and updating session attributes as appropriate.
Sessions may also provide access to a number of static session attributes. These are special read-only attributes that automatically exist in every session within the scope of a data service resource. An example of a static session attribute might be a Transaction Manager used to manage the stages of transactions distributed across multiple requests. No specific static session attribute implementations are provided as standard, but this is an extensiblity point that users may wish to exploit.
All perform document requests that are processed by a data service resource are joined to a session. However, a client may choose whether or not to specify particular requirements for the session it wishes to join. It is important to note that only one request may join a particular session at a time. In other words, an activity within one request may interact with a particular session, and after that request is complete another activity within a subsequent request may interact with the same session.
If no session requirements are specified for a request, then the request is automatically joined to an implicit session. This is a special kind of session that is created automatically for the purposes of a single request and terminated as soon as that request completes. Implicit sessions provide access to static session attributes but are not useful for storing state across multiple requests.
In order to make proper use of sessions for storing state across multiple requests, the client must provide the data service resource with explicit session requirements. These are specified using a <session> element within the perform document. The Client Toolkit APIs also provide a means of specifying the session requirements for a request. When a perform document request is submitted its session requirements can instruct the data service resource to:
More details of how the <session> element can be used to specify session requirements are provided on the Perform Document page and in the Client Toolkit Tutorial.
Each data service resource has its own internal session manager responsible for creating, accessing and terminating sessions. The session manager is configured using a session configuration document. This document specifies the default and maximum life-times for sessions as well any static session attributes that should appear in each new session. More details of session configuration can be found on the Session Configuration Documents page of the Reference Material section of the documentation.
| Back: Activities | Up: Interacting with Data Service Resources | Next: Perform Documents |
| © International Business Machines Corporation, 2002-2006 | © The University of Edinburgh, 2002-2006 |