> On Wed, Mar 09, 2005 at 02:52:52PM -0800, Richard Lynch wrote: >> > Agreed, initially I thought of that but I also need to use >> transactions >> > in my business logic and MySQL doesn't support nested transactions, so >> > I'd have to open a separate connection to the DB to handle the session >> > transaction while another connection handles the business >> > transaction(s). I'm hoping to find a solution that uses locking in >> the >> > application level instead of the database. Were I using a DB that >> > supported nested transactions, it would be a different story. maybe >> > it's time to switch databases. >> >> Since the data only changes when you write it, at the end of the script, >> you could maybe get away with the transaction only being in the >> session_save handler, and be sure to rollback or commit your business >> logic before that. >> >> That would for sure take a lot of discipline, and might even be >> downright >> impossible for what you need, but it's worth pondering. > > 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. But they other scripts are going to read their session data from the database, which is the way the world "is" at that point in time. More importantly, if you really lock it for the whole duration of the script, then youre frames/iFrames/whatever are gonna get real slow and clunky. Each frame will have to wait for the other frame to finish before it can read anything. Ugh! You'd really be better off designing your application so that some frames are "read-only" and don't alter data, and catch the error condition if two write-frames try to write out of sequence. I guess I'm saying that if you have to worry about this, the analysis and correction belongs in the business logic layer, not the session handling layer, in order to make iframes and tabbed multi-user useful. Or you can just "lock" the user into one iframe/tab at a time, and not allow them to open up a second session, by invalidating the previous session (frame/tab) when they open one up. 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. -- 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
