In addition to this, you may wish to consult I know what I mean. Why don't you?.

Thanks everyone :)

Looks like I've to look for an alternative solution for now, because I haven't found a fix yet.

Hope someone can enlighten me on this: Is it common to use Storable to store CGI session data? I'm thinking of trying that.

Is it common to use Storable to store CGI session data?

I don't know, and I don't really care. But I smell a race condition here. Are you using proper file locking to prevent two nearly parallel processes from overwriting the single storage file with out-of-date data?

File locking is highly OS dependant. There are several ways to lock a file, and most times, only one of them really protects you from race conditions. And it even gets worse when network drives are added. For that reason, and because I most times already have and use a database, I prefer using a relational database for storing sessions. It doesn't really matter which one, all of the big players (PostgreSQL, Oracle, MySQL, MS SQL Server) have working locking mechanisms, so I don't have to care about file locking. SQLite should also work, at least on a local file system on Unix derivates. I'm not sure about SQLite's file locking on Windows and on network drives, there may be problems.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

I'm not sure about the race condition. CGI::Session checks each request for a returned cookie. If there isn't one it allocates a unique session id and its own file (if you're using that option). The response contains a cookie with the id.

I'm thinking that you could get a race condition only if the same cookie came in at the same time (with, say, a different query string). I'm not sure how likely that would be and anyway a lot rarer than the OP is experiencing.

I'd be intrested to find out if I'm wrong. I'd have a lot of code to rewrite. :-)

Create a test program , with verbose logging, and run it for a few thousand interation locally, through localhost webserver, and through non-localhost webserver. Examine the log files.

You should be able to discover if the problem exists and where, or if its merely an illusion problem :)

Because it happens randomly, it was discovered by chance.

I followed up with more tests - manually - and confirmed the existence of the unexpected behaviour.

I'm clueless at this point - it's a bit like you have a variable set to "Hello World" and it's always printing "Hello World" but once in the blue moon you see "hello there" printed ;)

Clueless about what?

You contend there is a problem with CGI::Session, it happens randomly, but that you've confirmed it manually.

Great, here is how you go about fixing it.