Hi,

I'm getting some undesirable results with my shiny new OO session handling libs, so i'm posting here in the hope that someone has seen this before.

The libs work by using an 'abstract singleton', so you start a session by doing:

$sess = SessBase::singleton('SessDBHandler', new SessDBPersistance());

..where SessDBHandler is a class which inherits from SessBase, and the (private) constructor in SessBase actually calls session_set_save_handler(). SessDBPersistance is just a proxy for a small db abstraction lib, and the (final) destructor of SessBase calls session_write_close(), hence forcing the order of destruction of the objects so that the write, close and gc handler methods are called before the SessDBPersistance object is destroyed.

Basically, this work OK, but i've noticed that if you refresh a page lots of times in quick succession, the session_id is regenerated whilst the user still has a vaild session.

The open handler tries to update the expiry time on the current requests' row in the database, and if that operation returns 0 rows affected, it is inferred that the session has gone stale and needs to be refreshed (using the session_id() function to force re-generation).

It seems that when 2 requests come in from the same session in quick succession, the second request fails to update the database row in the open handler (even though the first request has already created a row which could be updated). This even happens with established sessions, i.e. the first of the pair of requests doesn't have to create a new row, because one alrady exists from before.

This looks to me like either a database caching issue, or a concurrency issue, with 2 apache threads serving the same user simultaneously.

I hope i've explained the problem well enough, please let me know if you don't understand something.

TIA
--Robin

ps. I'm unsing version 5.1.2 on Ubuntu, using the standard mysql extension (ie. no mysqli or PDO) and mysql5 (all libs are ubuntu packages).

    4 years later
    Write a Reply...