On Wed, Jun 07, 2006 at 01:24:38PM -0400, [EMAIL PROTECTED] wrote: > If it is inconvenient to rollback and retry the entire transaction, > then start the transaction initially with BEGIN EXCLUSIVE. This > will acquire the reserved lock immediately (instead of waiting to > the first write occurs) and so you will either get an SQLITE_BUSY > right away (when it is a simple matter to just rerun the BEGIN EXCLUSIVE > statement until it works) or you can be assured of never getting > another SQLITE_BUSY again until you try to COMMIT (and there too, > you can simply rerun COMMIT repeatedly until it works.)
It would be convenient to have another form of "BEGIN", in between DEFERRED and IMMEDIATE, whose effect was to immediately acquire the shared lock. That would allow read-only transactions to get this same level of programming convenience you describe, where one only has to be able to handle SQLITE_BUSY in one place. (Of course, one could simulate this now by immediately running a meaningless SELECT after each call to BEGIN, solely for the side-effect of acquiring the lock, but it seems less elegant and perhaps not guaranteed to continue working in the future.) -- Nathaniel -- .i dei jitfa fanmo xatra
