Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

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 (Archbishop) 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 all is quiet...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (6)
As of 2018-05-24 20:46 GMT
Find Nodes?
    Voting Booth?