Database Reference
In-Depth Information
it and unserialize it after retrieval. The conversion to and from serialized strings gen‐
erally is not something you must deal with when providing storage routines. It's nec‐
essary only to make sure the storage manager has a large enough repository in which
to store the serialized strings. For backing store implemented using MySQL, use one of
the
BLOB
data types. Our session managers use the largest such type,
LONGBLOB
. When
assessing storage needs, remember that stored data is serialized, which takes more space
than raw data.
The rest of the chapter shows a session-based script for each API. Each script performs
two tasks. It maintains a counter value that indicates how many requests have been
received during the current session, and records a timestamp for each request. In this
way, the scripts illustrate how to store and retrieve a scalar value (the counter) and a
nonscalar value (the timestamp array). They require very little interaction with the user,
who simply reloads the page to issue the next request. This results in extremely simple
code.
Session-based applications often include some way for the user to log out explicitly and
terminate the session. The example scripts implement a form of “logout” based on an
implicit mechanism: sessions have a limit of 10 requests. As you reinvoke a script, it
checks whether the counter limit has been reached and destroys the session data if so.
Because the session values are not present in the next request, the script starts a new
session.
To see the queries that MySQL-based session managers generate, watch the server's
general query log as you invoke session scripts from your browser. (The log must be
enabled; see
Recipe 22.3
.)
The example session scripts for Perl, Ruby, and PHP are located under the
apache
directory of the
recipes
distribution; the PHP session module is located in the
lib
directory; and the JSP examples are under the
tomcat
directory. SQL scripts for creating
the session storage tables are located in the
tables
directory. As used here, the session
tables are created in the
cookbook
database and accessed through the same MySQL
account as that used elsewhere in this topic. If you don't want to mix session management
activities with those pertaining to the other
cookbook
tables, consider setting up a sep‐
arate database and MySQL account to be used only for session data. This is true par‐
ticularly for Tomcat, where session management takes place above the application level.
You might not want the Tomcat server storing information in “your” database; if not,
give Tomcat its own database.
21.1. Using MySQL-Based Sessions in Perl Applications
Problem
You want to use session storage for Perl scripts.
