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. so... no luck finding a concurrency-aware database session handler? i'm going to try to roll my own, and i'll certainly share what i come up with on the list. thanks though, for the help up to this point! /jw -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
