--- Nathaniel Smith <[EMAIL PROTECTED]> wrote: > 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.)
Bill King's idea about using reader/writer locks is a much better idea and far less error prone and should be built into the SQLite library itself. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
