So, I've been struggling with this question somewhat lately. I have my exciting database driven website where users can search the database, and some users can update the database either by updating records or inserting records. Of course, when you display a record, it isn't really from one table, but rather from 11 different tables (one main table, 5 subinformation tables, and 5 intersection tables to maintain the one primary table with 5 one-to-many relationships). So when you find the record you're interested in, there are still a few more queries to render the whole thing.
So, my current thought: user begins a search, creates his/her criteria, and submits it. The app then creates a thread for that searches the database, after first making sure that a thread by that name is not currently running. If there is a thread by that name, it destroys that thread and then searches the database. That way if someone submits two searches in short duration, search1 creates it's own thread, then search2 destroys that thread entirely and continues to create it's own thread and search the database. All the parameters needed for this search are either in the request object or are initiated during the search procedure. Update should work the same way, except with some sort of thread death listener to run a rollback if the thread is killed mid-update (partial updates are bad!). Of course, like I've said before, this is my first foray into multiple threaded processes, so I figured I'd run this by anyone who's listening out there. Thanks for reading! Michael Nicholson
