> 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.
try BEGIN IMMEDIATE http://sqlite.org/lang_transaction.html
