On 10/29/07, Richard Klein <[EMAIL PROTECTED]> wrote: > But am I correct in assuming that one way that SQLite provides > serializable transactions is by automatically rolling back > transactions when necessary (and returning SQLITE_IOERR)?
No. That will happen in some specific unavoidable cases, but you cannot assume it will happen all of the time. What will most likely happen instead is that the first INSERT or UPDATE in a transaction will return SQLITE_BUSY, and you will have to roll back the transaction yourself. It's possible to continue within a transaction by ignoring an error from an individual statement (depending on the nature of the error), is why I make this distinction. It's also possible to simply keep retrying a failing statement until it succeeds, but in the case of INSERT or UPDATE that may lead to deadlock, as two connections that want to write cannot proceed until one of them yields. On the other hand, if you get SQLITE_BUSY on COMMIT, you probably want to retry it, as it's just waiting for other readers to go away first. Automatically rolling back then would be bad :) ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
