“We’re using both a database and cookies to implement the
personalization system. Why both? This personalization needs both a
short-term and long-term memory. For example, when people are
younger, they tend only to remember what happened 5 minutes ago,
but not 5 years ago. Yet as people grow older, they tend to
remember what happened 5 years ago, but not 5 minutes ago. Our
system cannot have either flaw — it needs to remember both 5
minutes (heck, 5 seconds) ago, as well as 5 days, months, or years
ago.”
“The database will be our long-term memory. It remembers the
visitor’s account information permanently, no matter how much time
has elapsed between accesses to the account. On the other hand, we
run into the problem of HTTP’s inherent statelesness. Granted, this
is not a problem that makes the nightly news (“tonight with Peter
Jennings, the inherent statelesness of HTTP and how it can harm
your children”). The problem, in a nutshell, is that the web has no
short-term memory whatsoever. As a result, a web application such
as our personalization system can’t rely on the web server to
remember information specific to a user as they move from one web
page to another within the site.
“We could query the database — our long-term memory — every
time the user navigates to another page within our site, but this
would be inefficient and put a lot of strain on the database.
Instead, we need a way to ‘preserve state’ (sort of like
marmalade), as they say, during the browsing session, without
relying on the database. There are numerous ways to approach this
matter, and one popular solution for Apache+mod_perl-based servers
is the module Apache::Session. Using this module you can
effectively create a global hash, tied to a long-term storage
method (filesystem, database), where you can store and access user
information from any Perl script running in the mod_perl
environment. Apache::Session is well supported and worth
investigating, but wasn’t appropriate for the site which inspired
our particular recipe.”