Hello, I have a question regarding sqlite's behavior when auto commit is disabled.
I have two conflicting transactions, A & B, where A is started first. B starts by executing some SELECT queries (which all succeed), then on the first UPDATE I get SQLITE_BUSY (as A is holding a conflicting lock). I was under the assumption that repeating the UPDATE until A releases its lock is enough, but what actually happens when I attempt this is that I get SQLITE_BUSY all the way through, even after A finishes. I came to the conclusion that I should restart the whole transaction instead of trying to repeat the failed UPDATE, but I would really like to avoid that (it's not feasible in the application). I'd rather use any means of declaring that a transaction requires an exclusive lock before it starts (perhaps by issuing an artificial UPDATE as the first query, although it's ugly...I wonder if sqlite provides a cleaner solution), so that I know if it's going to get blocked as early as possible. Thanks, Mahmoud ---------- This message was sent from a MailNull anti-spam account. You can get your free account and take control over your email by visiting the following URL. http://mailnull.com/
