On 3/8/06, John Stanton <[EMAIL PROTECTED]> wrote: > Try an EXCLUSIVE TRANSACTION.
This wouldn't help, as other processes need to read from the database. I still think it's a bug: A cannot COMMIT it's changes, because B's INSERT failed! That just doesn't make any sense to me. Why does B need to ROLLBACK changes that were unsuccessful in any case? The problem I'm trying to solve: I have several worker threads that modify some parts of the database. Each of these threads can take a long time to finish (They are indexing directories of servers). What I could do it the following: CREATE TABLE foo (server_id INT, bar TEXT, newRevision BOOL) - The search engine only looks for Data with newRevision = FALSE - Each worker thread (responsible for one specific server_id) writes (without transactions) with newRevision set to TRUE - At the end, each worker thread does DELETE FROM foo where newRevision==false AND server_id == x, followed by UPDATE foo SET newRevision==false where server_id == x But I find it kinda pointless to do a "poor mans transaction". Do I have to switch to PostgreSQL to get "independent" transactions?
