Fw: [PHP] Custom database session handler and data concurrent access from ajax request

----- Original Message ----- From: "Nicolas Quirin" <n.quirin@free.fr> To: <ceo@l-i-e.com> Sent: Thursday, May 03, 2007 6:22 PM Subject: Re: [PHP] Custom database session handler and data concurrent access from ajax request

Ok thanks a lot to confirm my problem. I have partially implemented a write/read session class handler (not the customized session save handler wich read/write data from database) This class is only a semaphore manager for read/write object in the current session. Semaphore is created if not existent, semaphore is acquired if free, blocking if process must wait for this ressource. From my first tests of it, less error occured... But having a semaphore by safe object stored in the current session is cost memory issue: a created semaphore must have a time to live equal to the life time of the current session since i could'nt know which script is executed before another and which script could remove the semaphore... So semaphore are removed by session garbage collector. :-s. This issue cannot support 10000 connected users...I think: 10000 * (nbsafeobjet * semaphore memory size) = ARGHHHHH To finish, I must create a file per semaphore since sem_get require an id generated with ftock()!!!!!!! Heavy issue.... Is this solution really bad? I have search and find another solution : flock() and create a file per safe objet in the session. ----- Original Message ----- From: "Richard Lynch" <ceo@l-i-e.com> To: <n.quirin@free.fr> Cc: <php-general@lists.php.net> Sent: Thursday, May 03, 2007 5:59 PM Subject: Re: [PHP] Custom database session handler and data concurrent access from ajax request

On Thu, May 3, 2007 4:45 am, n.quirin@free.fr wrote:

Sessions are managed in a mysql database, with autocommit enabled. I'm using mysql_pconnect in my handler to read/write session data (same user, same password, same host, always).

As noted in the user comments of the on-line manual, the sample code in the manual does not (last I checked) handle the race condition of multiple AJAX (or other) requests. Several work-arounds are proposed, I believe.

I'm asking if custom session handler must implement mutex system or anything to prevent concurrent access and terrible random errors of session writing/reading and more....Concurrent access does'nt seems to be safely managed natively...

Yes. You *do* need to deal with this, and the sample code on php.net doesn't do that. It only works for the Web 1.0 (?) idea of interaction with serial requests to alter session.

Any idea? comment? I can sent my session handler php class....

Some kind of lock/mutex/whatever will be needed -- which will make your AJAX calls serial, not parallel. So you want to MINIMIZE your session writing section of code, call session_write_close at the end of it, and do that as soon as possible at the tip-top of the script, to make the serial-ness of the scripts as low-impact as possible. Also re-consider if you really really need to cram as much "stuff" into a session as you originally architected. Often-times I've seen folks putting an awful lot of stuff in session data, and they don't NEED to, it was just "convenient" -- Once you start down the AJAX road, it seems to me like you want to re-think that "convenience" and go for minimalism of what you write into a session. But I ain't been down that road, so maybe I'm full of it. :-) -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php