Second, there is no concept of "loggin in" and "logging out" in this code. It assigns anyone who comes along a cookie with a session ID, and creates backend storage for that session. It never makes any attempt to delete anything from the database. Are you talking about some other code that you didn't post?

There is a session ID, $session{_session_id}. Is that what you're talking about?

Note that Apache::Session stores all data as a BLOB serialized by Storable, so removing a value from the session should not cause anything to be deleted from the database, it would just update the row for that session. Values are not stored as separate rows.

Yes, there's some code I didn't post (sorry):

the login code takes a username and password from a form, looks up the username in the DB, and checks to see if the password matches. If it does, it sets $session{userid} to the users userid.

The logout code simply sets $session{userid} to undef.

I may have discovered the problem. As I understand it, there should be a row in the sessions table for each cookie issued, right? I have *no* rows in my sessions table.

I can't shake the feeling that I've completely missed something in how the sessions code works.

You are correct, there should be one row in the table for each cookie issued.

I see one thing that may be causing problems. You are trapping errors from the attempted tie to Apache::Session::DBI, but only handling the error if it's from the user not having a saved session. It could be an error from the database, and it's being ignored. Put in an else on that $@ check to re-throw the exception with a die if it doesn't match the regex.

You know, this session code from the Mason site has a lot of problems. Are you sure there isn't something newer included in the distribution?