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
