note 15285 deleted from function.session-set-save-handler by irc-html
| From: | irc-html@php.net | Date: | Fri, 19 Apr 2002 00:17:16 +0000 |
| Subject: | note 15285 deleted from function.session-set-save-handler by irc-html | ||
| References: | 1 | Groups: | php.notes |
| Request: | Send a blank email to php-notes+get-29560@lists.php.net to get a copy of this message | ||
OK, here's my project:
I am writing a stand alone session daemon for PHP. This will allow multiple PHP web servers to
operate on the same session "database" without the overhead of SQL or NFS. My current
pre-alpha server gets 1400 to 1500 PHP session transactions (connect/read/write/disconnect) a second
on a single PII 450 with a session data string of 256 bytes. As long as the session stays below the
size of an ethernet packet and you are on a switched backbone, it can stay pretty
close to those numbers.
The problem with which I am faced is session concurrency. Take this code:
<?
session_register("fubar");
$fubar++;
...
... (do lots of stuff here)
...
?>
Now, At session "register" time, all the variables are read from what ever system you use
to hold them (mysql, postgres, files, etc.). The data is not posted back to the session system until
the end of the page.
If, for some reason a second user or a user's second browser window accesses the same session
data at the same time what happens to the value of fubar?
For example: browser window A connects and gets data, at the same time browser B does the same
thing. Both PHP sessions get a fubar value of, say, 5, both increment the value, then both update
the value of fubar at completion.
"fubar's" value will be 6, not 7 as would be correct.
The PHP session code has a few handlers: files, mm, and user. The only one which is safe to use in
this circumstance is the "files" handler. It uses the OS level file locking mechanism.
The mm module does not lock the session data, nor do any of user modules I have been able to find on
the net, nor would mine in its current form. My question is: is coherency a "real" problem
or is it a "theoretical" one? Will this be a problem in a real site?
To "fix" this would require a lot of hairy low level coding with lots of messy error
processing for lost connections, locking timeouts, signals to waiting threads, waiting for a state
on a remote machine, etc. Not that this wouldn't be a fun thing to do ;-( but, before I sign up
for a 2-6 month IPC multiprocessing project, I want to know if I really need to worry about it.