John Stanton wrote: > Perhaps a thread per open database sync'd on an event and driven by a > queue would give you contention-free operation and avoid the need to > ever have the DB locked. > > A thread would post its request to the queue then wait on an event > signifying completion.
That's a great approach. The only problem I see to that is what happens with, say, a user who's getting a portion of his or her results in a query, like you would with a page of Google search results? When user A wants the next page of search results, user B's query might already be in progress, messing up the whole thing. Unless, of course, I misunderstand the use of the query ID, and that's why the query ID exists. While we're on the topic of threads, though, I've also found some conflicting information in Michael Owens' book. In it, Owens states: "Starting with 3.3.1, you can pass connections around between threads as long as they are in the UNLOCKED state at the time of the transfer (the connection has no transaction open)." Doesn't this mean that multiple Web threads could interact with a given database as long as the LOCKED state is well-managed? I guess I'm confused still. -- David ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
