markw@xxxxxxxxxxxxxx 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 <sarcasm>"Web 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
