php sessions and memcache

[Matthew Glubb]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Have you though about, for Ajax, not storing the session state on the  
server side. Surely the client side would be best placed to manage  
user data, given that it is initiating all of the asynchronous  
communications. I know that this would add extra bandwidth overheads  
but maybe its worth it.

How does Google do it?

Matt

On 18 Jul 2006, at 13:16, Richard Thomas wrote:

> Its the same problem regardless
>
> With file based backends file locking to prevent corruption, not  
> "Two processes fight for CPU time" as mentioned in that article.
>
> In a normal PHP session there is a write EVERY page load.. Only 1  
> process can write to a file at a time so the other process gets  
> held up till the first process is done.
>
> This is the same with SQL, if 2 processes try to update a table at  
> the same time, MySQL does table level locking so the second process  
> has to wait for the first process to finish and the table lock to end.
>
> You can avoid that by
>
> 1. Reducing the amount of times your updates take IE not trying to  
> update all the session data when the session hasn't changed
>
> 2. Not doing any updates if there not needed.
>
> Richard Thomas - CEO
> Cyberlot Technologies Group Inc.
> 507.398.4124 - Voice
>
>
> Andy wrote:
>> On Mon, 2006-07-17 at 21:21 -0500, Richard Thomas wrote:
>>> The race condition comes from the locking of tables on multiple  
>>> updates to the table at the same time.
>>>
>>> There are a couple ways to help prevent that
>>>
>>> 1. I hash during the read and check the hash during the write, If  
>>> the hash has not changed I only update the expire time not the  
>>> whole session
>>>
>>> 2. I only update the expire time every X seconds, this way if  
>>> there are no changes to the session and its only been a few  
>>> seconds I don't waste resources updating
>>>
>>> 3. When I do update just the expire time I do it low priority
>> Uh, at this point, I think we're talking about different things, so
>> nevermind.
>>> Andy wrote:
>>>
>>>> It was actually written to see if session updating race  
>>>> conditions could
>>>> be avoided when, using Ajax, multiple interleaved code paths run
>>>> against, and update, the same session.
>> The race condition I'm referring to, and that I had solved for, is
>> mentioned at
>> http://ajaxian.com/archives/troubles-with-asynchronous-ajax- 
>> requests-and-php-sessions
>> which transcends the storage backend used.



m a t t h e w   g l u b b

________________________________________________________________________
Z Group PLC

Tel: +44 (0) 8700 111 173
Fax: +44 (0) 8707 051 393
Txt: +44 (0) 7800 140 877
Web: <http://www.zgroupplc.com/>

This  email  and  any  files  transmitted  with it are  confidential and
intended solely for the use of the individual or entity to whom they are
addressed.  The opinions  expressed in this mail are those of the author
and do not necessarily  represent the views of the company.  If you have
received this email in error please notify <service at zgroupplc.com>



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEvNoOyI6MkdKPngkRAjmwAJsEbk5iz7BiiooG0NXCI6+8xRaIMwCdEEyN
p0q3xq7NmLk75HOZAhU9Z1Q=
=b9dY
-----END PGP SIGNATURE-----