Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49789
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ubuntu.com from 91.189.90.139 cause and error)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <3490ECDBA37FA3429C303BBB9BCC76325ECD1C945D@LMCU-BAL.services.alm>
Date: Sun, 26 Sep 2010 08:23:40 -0700
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <C629429E-1286-4126-B959-2D22092C2C34@ubuntu.com>
References: <3490ECDBA37FA3429C303BBB9BCC76325ECD1C945D@LMCU-BAL.services.alm>
To: ROZE Samuel <sroze@lillemetropole.fr>
Subject: Re: [PHP-DEV] Sessions lock - not using memcached?
From: clint@ubuntu.com (Clint Byrum)


On Sep 26, 2010, at 1:10 AM, ROZE Samuel wrote:

> Hello,
>=20
> I'm working with sessions in my PHP applications. My pages can take =
long time to be executed (~500ms) and I've simultaneous requests for the =
same session (Ajax requests). My problem is that I close sessions at the =
end of my PHP script, so my sessions files are locked for half a second. =
So, simultaneous requests (for the same session) can't be executed... =
simultaneously!
>=20
> My question is if I use memcached to store sessions, will my sessions =
be locked or can I access to them in the same time? If there aren't it =
should solve my problem.
>=20
> A second question is performances: is memcached sessions faster the =
PHP default sessions? I think yes because it doesn't make disk I/O..?
>=20

No, the default memcache session handler has no locking.

But that presents you with a new problem of a race condition.

This is why you shouldn't keep any actual data in sessions:

R1:[initial request start, session is read and has X=3D1]
A1:[ajax request 1 reads session, X=3D1]
A2:[user clicks "add 1 to my shopping cart", X =3D X+1 =3D 2]
A2:[displays shopping cart with X =3D=3D 2]
A2:[faster than A1, session over, write session with X =3D 2]
A1:[session over, write session with X =3D 1]

DOH!

There has to be some kind of locking on data between read/write to =
maintain consistency.

One way you can get around this is by *not* using the session for =
mutable data, and just using it to store a key to the data in your =
backend, and then only writing when you must.

The above becomes

R1:[initial request start, session is read and has shopping cart SID=3D1]
A1:[ajax request 1 reads session, SID=3D1]
A2:[user clicks "add 1 to my shopping cart", UPDATE carts SET X =3D X + =
1 WHERE SID =3D 1]
A2:[displays shopping cart with X =3D=3D 2]
A2:[faster than A1, session over, write session with SID=3D1]
A1:[session over, write session with SID=3D1]

Also, the memcache session handler can be dangerous in that it might =
choose to delete your session before expiration if memcached fills up, =
so be aware of this.

Good luck!