It is as easy as declaring a hash, tieing this hash to an Apache::Session::MySql-object and the data in the hash are silently and transparently persisted into the database.

Have a look at the docs in Apache::Session which are very clear.

You can look at all the stuff that's already in an established session DB with something like this:

use Data::Dumper;
$Data::Dumper::Terse = 1;
$Data::Dumper::Indent = 1;
use DBI;
use Apache::Session::MySQL;

my $dbh = DBI->connect('DBI:mysql:apache_session' .
                       ':' . 'localhost' .
                       ';mysql_read_default_file=/path/to/.my.cnf',
                       undef, undef,
                      );

( my $sth = $dbh->prepare('SELECT id FROM sessions') )->execute;
while ( my $id = $sth->fetchrow_array ) {
    my %session;
    tie %session, 'Apache::Session::MySQL', $id, {
                                                  Handle     => $dbh,
                                                  LockHandle => $dbh
                                                 };
    print Dumper \%session;
# you could edit or do whatever to %session here and get the
# data back with the same $id later
}
$sth->finish;
$dbh->disconnect;
[download]

For creating and manipulating the sessions, you should use the module itself, as CountZero suggested. It is in control of the "a_session" column's data (just a text field) and its serialization/retrieval, and you should almost certainly leave it that way.

While I am sure this problem has been solved since the original post was submitted I figured I would make a suggestion in regard to viewing session.a_session data in MySQL. What is stored in the session.a_session isn't visible by "SELECT a_session FROM sessions WHERE id=?" ... Apache::Session serializes the data before inserting it.

Once your session has been created and your additional session-data has been assigned to your tied hash ($session{foo} = "bar";), dump %session on a SUBSEQUENT VISIT and view the available data. If all works as planned, you will see foo => "bar" along with your session id.

Another (down & dirty) way to verify that session.a_session is indeed receiving the specified data is to "less session.MYD" (MySQL data file) on your web server ... assuming you have access. The output may be hard to understand but you should be able to recognize a session variable here or there.
Just a thought.

author => jeyroz