Database Reference
In-Depth Information
• For Java-based web applications running under the Tomcat web server, Tomcat
provides session support at the server level. Tomcat uses temporary files by default,
but you need only modify a server or application configuration file to use MySQL
for session storage. There are no changes to application programs, which need do
nothing to select one session backing-store method or another.
Session support for different APIs can use very different approaches. For Perl, the lan‐
guage itself provides no session support, so a script must include a module such as
Apache::Session explicitly if it wants to implement a session. Ruby is similar. In PHP,
the session manager is built in. Scripts can use it with no special preparation, but only
as long as they want to use the default storage method (files). To use an alternative
method (such as storing sessions in MySQL), an application must register its own rou‐
tines with the session manager. Still another approach is used for Java applications run‐
ning under Tomcat, because Tomcat itself manages many of the details associated with
session management, including where to store session data. Individual applications
need not know or care where this information is stored.
Despite their differences, session management implementations typically perform a
common set of tasks:
• Determine whether the client provided a session ID. If not, generate a unique ses‐
sion ID and send it to the client. Some session managers transmit the session ID
between the server and the client automatically. PHP does this, as does Tomcat for
Java programs. The Perl Apache::Session module leaves it to the application devel‐
oper to manage ID transmission.
• Store values into the session for use by later requests and retrieve values placed into
the session by earlier requests. This involves any activity that uses session data:
increment a counter, validate a login request, update a shopping cart, and so forth.
• Terminate the session when it's no longer needed. Some session managers can expire
sessions automatically after a period of inactivity. Sessions may also end explicitly,
if the request indicates that the session should terminate (such as when the client
selects a logout action). In response, the session manager destroys the session re‐
cord. It might also be necessary to tell the client to release information. If the client
sends the session identifier in a cookie, the application should instruct the client to
discard the cookie. Otherwise, the client may continue to submit it after it no longer
applies. Another approach to session “termination” is to delete all information from
the session record. This causes a new session to start with the client's next request
because no previous session information is available.
Session managers impose little constraint on what applications can store in session
records. Sessions usually can accommodate various types of data, such as scalars, arrays,
or objects. To make it easy to store and retrieve session data, session managers typically
serialize session information by converting it to a coded scalar string value before storing
