The Problem: What if the user logs in twice and submits Form #1 twice in a row? Then information from one login's submittal could bleed into the next. But if Form #1 could gain an exclusive lock on the query object file and hold it until Form #2 releases it then the problem would be solved: the potential race condition would be avoided because the second login would never get to submit Form #1 if someone else had locked it.

Use session IDs and something like Cache::Cache to manage the sessions. I have many columns that show how to do that.

-- Randal L. Schwartz, Perl hacker

Looking at the previous discussions on this, I've seen the code below. I was wondering if you were in a mod_perl enviroment, couldn't the same process call the function to generate the session twice in a second? I know with the random component that it's unlikely to have a collision but to be safe I've been using Timer::HiRes, is this overkill?

# How I've seen it suggested
use MD5;

sub generate_id {
    return substr(MD5->hexhash(time(). {}. rand(). $$. 'blah'), 0, 16)
+;
}

# Is this better or overkill?
use Time::HiRes qw(gettimeofday usleep);
use Digest::MD5 qw(md5_hex);

sub generate_sessionID {


    my ($s, $usec) = gettimeofday;    # Get time of day in seconds and
+ useconds

    usleep(1);    # Sleep for one usec so a persistant process can't c
+all it twice in a usec (for mod_perl)

    # Sessionkey is MD5 hash of seconds_since_epoch+usecs+process_id+r
+andom
    return substr(md5_hex($s.$usec.$$.rand()), 0, 32);
    

}
[download]



-Lee

"To be civilized is to deny one's nature."