> 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. 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
