> I think most people don't use Apache::Session::File in production. It's
> more of a testing thing. In your situation, you would probably get
> great performance from MLDBM::Sync with SDBM_File. I'd suggest trying
> that if you can't determine the cause of the Apache::Session::File issues.
Not to say that the other options won't work, but we're using
Apache::Session::File in production with no issues, handling in excess of
30 hits per second. It works fine, and it's easy to keep old session
files cleaned up with a simple cron job that finds and deletes session
files older than some limit.
During development we also noticed race conditions with near-simultaneous
pageloads into framesets. Try the 'Transaction' option when you tie to
the session - here is how that part of our mod_perl handler looks:
========================================
# NOTE:
# At this point, $session_id is either set to some
# value from a cookie (for an existing session)
# or it is "undef"
my %session = ();
my $opts = {
Directory => "$SESSIONFILEROOT/$site",
LockDirectory => "$SESSIONLOCKROOT/$site",
Transaction => 1,
};
eval {
tie %session, 'Apache::Session::File', $session_id, $opts;
};
if ( $@ ) {
# Session tie failed for some reason. If it was because
# an existing session is invalid, create a new session:
if ( $@ =~ /^Object does not exist in the data store/ ) {
$session_id = undef;
eval {
tie %session, 'Apache::Session::File', $session_id, $opts;
};
}
if ( $@ ) {
# Totally failed to create the session - bail out:
$r->log_error( "Tie failed: $@");
return SERVER_ERROR;
}
}
========================================
HTH,
Larry Leszczynski
[EMAIL PROTECTED]
