session_write_close() is also nice in that freeing the lock doesn't destroy your existing copy of the session variables, you can still use them in the rest of your script just remember that they exist in your current script as they were when you called session_start(), even if some other script modifies the session, you won't know until your next call to session_start(). Be careful using data from an unlocked session to to modify that data later on, as another instance can modify the session in between. Only release the lock when you really don't care if it's modified elsewhere. On Sat, 12 Mar 2005 14:50:44 -0600, Josh Whiting <jw-php@xxxxxxxxxxxxxx> wrote: > On Fri, Mar 11, 2005 at 09:57:46AM -0800, Richard Lynch wrote: > > > well the trouble is not in the writing at the end of the request, which > > > would likely only be a single query and therefore not need a transaction > > > in itself. the trouble is the lack of locking out other requests from > > > reading the data when you're using it during the main body of > > > the request. > [...] > > Short Version: Either your frames/tabs are gonna be so clunky as to be > > useless, or you need to lock them into only one, or you need business > > logic, not session-logic. Solving the race condition at session layer > > will only make your application un-responsive. > > > > This may go a long way to explaining why you're not finding any readily > > available solutions out there at the session layer. > > You raise good points. However, my goal is simply to have a > transparent, database-driven replacement for PHP's native session > handler. I don't want to change my application logic because I'm > switching session handlers - my application shouldn't care! And so, > transparently reproducing PHP's session layer functionality is going to > mean locking concurrent requests out, because that is what PHP's session > handler already does (for good reason IMHO). > > you're argument about slow frames is valid, but is ALSO applicable to > PHP's native session handler, e.g. i'm not introducing a new problem. > the trouble can be mostly avoided in either case by not starting session > in frames that don't need it (most of them), and doing any session stuff > right away and calling session_write_close() ASAP to free up the lock so > other frames can run. > > you're right that i could change my application logic to deal safely > with concurrent requests from the same session, but PHP already nicely > defeats the issue so you don't have to worry about it, and at a more or > less negligable performance loss if you design the scripts to reduce > session open/locked time to the bare minimum... > > i would speculate that the reason i haven't found a readily available > solution is because most folks either (1) don't understand the problem, > or (2) don't think such a race condition is likely enough to warrant a > fix, or (3) are using a different backend (oracle, etc.) that makes the > problem easy to solve. the PHP team, however, clearly thought it was > important enough as is evident by their session handler design. > > ...have i convinced you yet of the worthiness of this endeavor? :) > > /jw > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
