• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Session Class using database - multiple Ajax requests - concurrency problem leeds to lost update in session data

Hi folks,

I just stumbled upon a strange behaviour of the CI session class using the data base as soon as ajax is an issue. The problem is that user session data is sometimes lost when multiple ajax calls are done. The only reason for this is – in my opinion – the fact, that the CI session class is not safe against multiple requests with the same session ID if the requests are done with nearly no time-lag. It seems there is a race condition which leads to a “lost update” problem in the data base.

The scenario is as follows:

The web side executes two ajax requests (Request A and Request B) at the same time.

Request A is processed and the session data is retrieved from the database.
Request B is processed and the session data is retrieved from the database.
Request A changes the session data and the session is written to the data base.
Request B changes the session data and the session is written to the data base.

The information passed by Request A is lost due to the fact that the Request B is operating on an outdated version of the session data. In the end only the changes made by Request B are saved in the session.

So the problem only occurs sometimes as it seems to depend on the order and the timing of the requests. If Request A is fast enough everything works fine as the changes made are written to the database before Request B reads the session data.

Is this a possible scenario or am I missing something in the way CI works in this case? To me it is the only possible explanation for the (miss-) behaviour of our application. If I’m right, the question is how to fix this problem – as it is an ajax-only problem. But it might be an issue in any ajax application using CI. Using third party GUI or charting libraries makes it hard (sometimes impossible) to merge the two requests into one. And you would loose the main advantage of the ajax thing: multiple (parallel) requests… ;-)

One solution would be to fix the session class just to read the session data again just before writing and check whether the data has changed (timestamp or hash). This should be done as an database transaction. At this point I think it could be an individual solution only as it might depend on the application what to do if a change in user data is detected.

What is your opinion to this point? Has anybody had a similar problem and how did she fix it?


Hi, im having the same issues, do you found a solution?



Well, we’re working on a solution that will fit to our needs. Bit this needs some testing. As soon as I consider our solution as „stable“, I’ll let you know.

The solution might be to read the session date again and then insert the new value just before writing the new session data into the database (session.php => sess_write ()). This must be done in an atomic function (transaction). This is just a solution for the lost update problem – any parameter change in both requests will still be dominated by the slowest request. But I can’t see any reason why the same parameter should be change by both requests. This constellation might be a design fault anyway… ;-)

In general most people just give you the advice to simply avoid the situation where this problem occurs as it is a general problem also in php native session handling. Personally I think avoiding might not be that simple at all… ;-)


Thanks, for now this works for me http://ellislab.com/forums/viewreply/577954/


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  

  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2021 MyBB Group.