Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Randomness encountered with CGI Session

by Anonymous Monk
on Jun 09, 2010 at 03:29 UTC ( #843795=perlquestion: print w/replies, xml ) Need Help??
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:


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?

  • Comment on Randomness encountered with CGI Session

Replies are listed 'Best First'.
Re: Randomness encountered with CGI Session
by ww (Bishop) on Jun 09, 2010 at 12:10 UTC
    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?.

      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.


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

Re: Randomness encountered with CGI Session
by Anonymous Monk on Jun 09, 2010 at 04:18 UTC
    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 :)

      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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://843795]
Approved by wfsp
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (9)
As of 2016-09-26 12:49 GMT
Find Nodes?
    Voting Booth?
    Extraterrestrials haven't visited the Earth yet because:

    Results (478 votes). Check out past polls.