----- Original Message -----
From: "Nicolas Quirin" <n.quirin@xxxxxxx>
To: <ceo@xxxxxxxxx>
Sent: Thursday, May 03, 2007 6:22 PM
Subject: Re: 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@xxxxxxxxx>
To: <n.quirin@xxxxxxx>
Cc: <php-general@xxxxxxxxxxxxx>
Sent: Thursday, May 03, 2007 5:59 PM
Subject: Re: Custom database session handler and data concurrent
access from ajax request
On Thu, May 3, 2007 4:45 am, n.quirin@xxxxxxx 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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
