Randomness encountered with CGI Session

[Anonymous Monk]

Hi,

I'm seeing this behaviour when using CGI::Session. Most times, the session data is updated when moving from one web session to another - which is the expected behaviour. But occasionally, the updating does not happen.

I can't figure what the cause is because of the randomness.

I've added $session->flush at the end of the code setting session values, but I'm not sure if that will resolve the issue.

Has anyone encountered this before?

[ww]

Monks may be able to answer your explicit question - "(h)as anyone encountered...?" - but helping you diagnose your problem will require a bit more information -- specificly, code and info about the tests you performed after discovering the problem.

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

[Anonymous Monk]

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.

[afoken]

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

[wfsp]

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. :-)

[Anonymous Monk]

How are you seeing this behavior?

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 :)

[Anonymous Monk]

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 ;)

[Anonymous Monk]

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.