3.1.5.3 Saving Session Data with a Set Request

When a client needs to store session data in an out-of-process state server, it makes a request to the state server by using the message format that is specified in section 2.2.5.5.

A state server MUST associate the session data that is contained in this message with a unique identifier that is created from the combination of application-identifier, appdomain-identifier, and session-identifier. A state server MUST not interpret these values or assign any specific relevance to them. Rather, a state server implementation MUST simply use the combination of those values as the unique identifier for storing session state associated with the combination of those identifiers.

The state server MUST send a response back to the client by using one of the message formats that are specified in section 2.2.5.6.

If the state server does not currently have any session data associated with the requested identifier, it MUST store the session data contained in the message.

If the client sent the optional extra-flags value, the state server MUST also store this information along with the session state data. The state server MUST be able to return this value in the action-flags value of the response messages, as specified in sections 2.2.5.2 and 2.2.5.4.

The state server MUST also store the time-out value that is sent from the client. This time-out value is returned as part of the response-ok messages that are specified in sections 2.2.5.2 and 2.2.5.4. This value is also used when refreshing session state time-outs by using the message as specified in section 2.2.5.11.

Internally, the state server MUST also store the date and time of the current request to save session state. This date and time information is necessary for the state server to remove out-of-date session data. In order to prevent memory or storage exhaustion from storing data for an infinite time period, a state server implementation MUST implement some type of cleanup or scavenging mechanism that can detect expired sessions. A session is considered expired if the current date and time is greater than the session time-out value that is added to the date and time of either the last Set_Request message or the last ResetTimeout_Request message.

If the state server successfully stored the session state, it MUST return a response-ok message.

If the state server does currently have session data associated with the requested identifier, and the client sent the optional extra-flags value, and the optional extra flags value is set to 1, the state server MUST NOT store the session data contained in the message.  Instead the state server MUST immediately return a response-ok message.

If the state server is already storing session data that is associated with the requested identifier, but the session data is locked by another request (that is, two or more clients are simultaneously running, and each client is using the same identifier), the state server MUST NOT store the session data contained in the message.  Instead the state server MUST respond by using a response-locked message, as specified in section 2.2.5.6. The response-locked message contains a lock-age (section 2.2.3.10) and lock-date (section 2.2.3.8) in addition to the value of the current lock-cookie. The lock-cookie is an integer representation of the current lock. The lock-date value MUST contain the date and time the existing lock was placed on the session state data. The lock-age header MUST contain a representation for the age of the current lock.

The response-bad-request message, as specified in section 2.2.5.6, is conceptually equivalent to throwing an exception. The session state server MUST send this message if something goes wrong and the server is unable to process the request.