Re: [PHP] Recursing sessions?
markw@mohawksoft.com wrote: On Sat, July 1, 2006 5:30 pm, Mark wrote: If the frames do any sort of processing on the session information, as is the case with squirrelmail, the last session to exit will overwrite all the changes made by prior frames. This can corrupt session information or lose versions of information. It is a HUGE problem that I don't see ANYONE addressing. Ah. Now I know which question you are asking... The built-in PHP session handler handles this by LOCKING the session for writing until it is closed and done for each request. The simplistic example for user-defined handling sessions in the manual does not, in fact, address this directly. The User Contributed Notes, last I checked, did have some rather sarky comments about this issue, and some suggestions for how to fix it. If you are using a database, for example, locking via some mechanism in the DB is probably a viable solution. Wrapping it all in a Transaction is probably overkill, for example, but would work. Of course, the simplest solution remains: Don't use frames. In the world of sarcasmWeb 2.0/sarcasm This problem is only going to get worse. I think I have a solution, MCache, which is based on MSession, but I don't see the core PHP group liking it too much. which every solution is used some kind of polling/locking mechanism will have to be used. I can't comment on whether the 'locking' loop you showed on the list is any good in practice because my C sucks and my understanding of networks is in the same ballpark but from what I gather your solution is correct (and required) in principle. with SquirrelMail you don't want to change the code but in your own applications that have the same issue you can mitigate the waiting caused by locking by setting session data as early as possible, likewise grabbing all 'read-only' data from the sesssion and then calling session_write_close() at the earliest opportunity (making sure your implementation frees the lock at the stage) so that concurrent requests don't have to actually waiting until the previous request is complete (but only wait just until a previous request is done with the session mechanism. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Recursing sessions?
markw@mohawksoft.com wrote: On Sat, July 1, 2006 5:30 pm, Mark wrote: If the frames do any sort of processing on the session information, as is the case with squirrelmail, the last session to exit will overwrite all the changes made by prior frames. This can corrupt session information or lose versions of information. It is a HUGE problem that I don't see ANYONE addressing. Ah. Now I know which question you are asking... The built-in PHP session handler handles this by LOCKING the session for writing until it is closed and done for each request. The simplistic example for user-defined handling sessions in the manual does not, in fact, address this directly. The User Contributed Notes, last I checked, did have some rather sarky comments about this issue, and some suggestions for how to fix it. If you are using a database, for example, locking via some mechanism in the DB is probably a viable solution. Wrapping it all in a Transaction is probably overkill, for example, but would work. Of course, the simplest solution remains: Don't use frames. In the world of sarcasmWeb 2.0/sarcasm This problem is only going to get worse. I think I have a solution, MCache, which is based on MSession, but I don't see the core PHP group liking it too much. which every solution is used some kind of polling/locking mechanism will have to be used. I can't comment on whether the 'locking' loop you showed on the list is any good in practice because my C sucks and my understanding of networks is in the same ballpark but from what I gather your solution is correct (and required) in principle. I am concerned about this problem for a few reasons. I suspected it was a problem for a while, but never really gave it much thought. I mean, geez, I've worked on a lot of parallel systems and just didn't think about it. Maybe I give myself too much credit, but if I miss the clues, I'm sure that a ton of other qualified people have as well. In fact, I see more than a few session management system that take proper serialization for granted. In the old days you could, more or less, rely on a single browser/connection. With frames (not that frames are new) and AJAX methodologies, the nature of the problem is really a distributed locking problem. On top of that, with AJAX and more true web applications make this a more and more serious issue. with SquirrelMail you don't want to change the code but in your own applications that have the same issue you can mitigate the waiting caused by locking by setting session data as early as possible, likewise grabbing all 'read-only' data from the sesssion and then calling session_write_close() at the earliest opportunity (making sure your implementation frees the lock at the stage) so that concurrent requests don't have to actually waiting until the previous request is complete (but only wait just until a previous request is done with the session mechanism. Coding around the problem is not solving the problem. If you force yourself to have to deal with concurrency every time you get data, you are creating a lot of complexity solving the problem in the wrong place. The data storage system should deal with it. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Recursing sessions?
On Sat, July 1, 2006 5:30 pm, Mark wrote: If the frames do any sort of processing on the session information, as is the case with squirrelmail, the last session to exit will overwrite all the changes made by prior frames. This can corrupt session information or lose versions of information. It is a HUGE problem that I don't see ANYONE addressing. Ah. Now I know which question you are asking... The built-in PHP session handler handles this by LOCKING the session for writing until it is closed and done for each request. The simplistic example for user-defined handling sessions in the manual does not, in fact, address this directly. The User Contributed Notes, last I checked, did have some rather sarky comments about this issue, and some suggestions for how to fix it. If you are using a database, for example, locking via some mechanism in the DB is probably a viable solution. Wrapping it all in a Transaction is probably overkill, for example, but would work. Of course, the simplest solution remains: Don't use frames. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Recursing sessions?
On Sat, July 1, 2006 5:30 pm, Mark wrote: If the frames do any sort of processing on the session information, as is the case with squirrelmail, the last session to exit will overwrite all the changes made by prior frames. This can corrupt session information or lose versions of information. It is a HUGE problem that I don't see ANYONE addressing. Ah. Now I know which question you are asking... The built-in PHP session handler handles this by LOCKING the session for writing until it is closed and done for each request. The simplistic example for user-defined handling sessions in the manual does not, in fact, address this directly. The User Contributed Notes, last I checked, did have some rather sarky comments about this issue, and some suggestions for how to fix it. If you are using a database, for example, locking via some mechanism in the DB is probably a viable solution. Wrapping it all in a Transaction is probably overkill, for example, but would work. Of course, the simplest solution remains: Don't use frames. In the world of sarcasmWeb 2.0/sarcasm This problem is only going to get worse. I think I have a solution, MCache, which is based on MSession, but I don't see the core PHP group liking it too much. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Recursing sessions?
Richard Lynch wrote: On Fri, June 30, 2006 11:11 am, Mark wrote: Here is a problem I am seeing, A browser hits a site the uses frames, for the sake of argument, lets call this site a squirrelmail web mail server. The browser seems to spawn a number of requests at the same time (I think one for each content frame), I get multiple PS_READ_FUNC calls, and then get multiple PS_WRITE_FUNC calls. Last PS_WRITE_FUNC call wins. Anyone else see this? Of course. Anyone have a good fix? As I recall, you HAVE to get the OUTER php page, with the FRAMESET in it, to start the session, and then in that page, all the FRAME page requests will be using the same session, because it has already been established. I think I even went so far as embedding the session_id in the URLs for the FRAME SRC=...SID=SID and then I made sure each frame page was using that ID. That doesn't fix the problem at all. The problem isn't the creation of the session, it is the simultaneous access of the session data without synchronization. When a browser a frame set, it will request all the frame at once. If the frames do any sort of processing on the session information, as is the case with squirrelmail, the last session to exit will overwrite all the changes made by prior frames. This can corrupt session information or lose versions of information. It is a HUGE problem that I don't see ANYONE addressing. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Recursing sessions?
[snip] Here is a problem I am seeing, A browser hits a site the uses frames, for the sake of argument, lets call this site a squirrelmail web mail server. The browser seems to spawn a number of requests at the same time (I think one for each content frame), I get multiple PS_READ_FUNC calls, and then get multiple PS_WRITE_FUNC calls. Last PS_WRITE_FUNC call wins. Anyone else see this? Anyone have a good fix? [/snip] I have a question. This is PHP related how? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Recursing sessions?
[snip] Here is a problem I am seeing, A browser hits a site the uses frames, for the sake of argument, lets call this site a squirrelmail web mail server. The browser seems to spawn a number of requests at the same time (I think one for each content frame), I get multiple PS_READ_FUNC calls, and then get multiple PS_WRITE_FUNC calls. Last PS_WRITE_FUNC call wins. Anyone else see this? Anyone have a good fix? [/snip] I have a question. This is PHP related how? I am debugging a PHP session manager and this behavior is keeping the system from working correctly. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Recursing sessions?
[snip] I am debugging a PHP session manager and this behavior is keeping the system from working correctly. [/snip] A more descriptive explanation along with some code will help us to help you. AFAICS we do not have enough information to go on. Does each frame generate its own session? Can you show us that? The last session setter always wins if the variables are the same. So, if I say; $_SESSION['user'] = 'foo'; $_SESSION['user'] = 'bar'; echo $_SESSION['user']; Like any good variable will return its last given value; bar -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Recursing sessions?
Jay Blanchard wrote:
[snip]
I am debugging a PHP session manager and this behavior is keeping the
system from working correctly.
[/snip]
A more descriptive explanation along with some code will help us to help
you. AFAICS we do not have enough information to go on. Does each frame
generate its own session? Can you show us that? The last session setter
always wins if the variables are the same. So, if I say;
$_SESSION['user'] = 'foo';
$_SESSION['user'] = 'bar';
echo $_SESSION['user'];
Like any good variable will return its last given value;
Sorry, here's more information:
I have a remote session system, like a database or a cache.
I have an Apache server running PHP 5 (although it does it on 4.x as well)
I am running Squirrelmail on the server.
Squirrelmail has frames.
The frames on squirrelmail each use the same session information
Multiple frame requests are sent from the browser at the same time.
The time to handle the requests is a non-zero amount of time that varies
with each frame
session_start is called for each frame request
The frame pages are processed
The session information saved via (I believe) session_write_close for the
frame requests
as each frames modifications to the session data is saved, the last session
to finish ends up writing the final version of the session data.
A log looks like this:
PS_READ_FUNC()
PS_READ_FUNC()
PS_WRITE_FUNC()
PS_WRITE_FUNC()
It should look like this:
PS_READ_FUNC()
PS_WRITE_FUNC()
PS_READ_FUNC()
PS_WRITE_FUNC()
In my session handler code, I have added a loop that looks like this:
for(tstart=time(0); elapsed 30; elapsed = time(0) - tstart)
{
stat = network_lock(xkey);
if(stat==LOCK_OK)
{
NETLOCK_G(fdlock) = xkey;
break;
}
sleep(1); // Connection is busy, sleep for a second
}
This fixes the problem, but requires that PHP poll. I can put the same login
the the network system, but then that requires a socket and perhaps a
thread.
Does PHP have a way to tell the browser to respond once frame at a time, or
some more efficient serialization methodology.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Recursing sessions?
On Fri, June 30, 2006 11:11 am, Mark wrote: Here is a problem I am seeing, A browser hits a site the uses frames, for the sake of argument, lets call this site a squirrelmail web mail server. The browser seems to spawn a number of requests at the same time (I think one for each content frame), I get multiple PS_READ_FUNC calls, and then get multiple PS_WRITE_FUNC calls. Last PS_WRITE_FUNC call wins. Anyone else see this? Of course. Anyone have a good fix? As I recall, you HAVE to get the OUTER php page, with the FRAMESET in it, to start the session, and then in that page, all the FRAME page requests will be using the same session, because it has already been established. I think I even went so far as embedding the session_id in the URLs for the FRAME SRC=...SID=SID and then I made sure each frame page was using that ID. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
