Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.
Any connection scope variables and temporary tables created and altered within the HTTP session are accessible to subsequent HTTP requests that specify the given SessionID. The SessionID can be specified by a GET or POST HTTP request method or specified within an HTTP cookie header. When an HTTP request is received with a SessionID variable, the server checks its session repository for a matching context. If it finds a session, the server utilizes its database connection for processing the request. If the session is in use, it queues the HTTP request and activates it when the session is freed.
The sa_set_http_option can be used to create, delete and change session ids.
HTTP sessions require special handling for management of the session criteria. Only one database connection exists for use
by a given SessionID, so consecutive client requests for that SessionID are serialized by the server. Up to 16 requests can
be queued for a given SessionID. Subsequent requests for the given SessionID are rejected with a
503 Service Unavailable status when the session queue is full.
When creating a SessionID for the first time, the SessionID is immediately registered by the system. Subsequent requests that modify or delete the SessionID are only applied when the given HTTP request terminates. This approach promotes consistent behavior if the request processing results in a roll-back or if the application deletes and resets the SessionID.
The current session is deleted and replaced with the pending session when an HTTP request changes the SessionID. The database connection cached by the session is effectively moved to the new session context, and all state data is preserved, such as temporary tables and created variables.
For a complete example of HTTP session usage, see %SQLANYSAMP16%\SQLAnywhere\HTTP\session.sql.
Stale sessions should be deleted and an appropriate timeout should be set to minimize the number of outstanding connections because each client application connection holds a license seat. Connections associated with HTTP sessions maintain their hold on the server database for the duration of the connection.
For more information about licensing in SQL Anywhere, see http://www.sybase.com/detail?id=1056242.
How to create an HTTP session
How to detect an inactive HTTP session
How to delete an HTTP session or change the session ID
HTTP session administration
HTTP session error codes
Discuter à propos de cette page dans DocCommentXchange.
|Copyright © 2013, SAP AG ou société affiliée SAP - SAP Sybase SQL Anywhere 16.0|