On 6/7/07, David Glasser <glasser@mit.edu> wrote:
> My impression was that the sqlite3 mergeinfo database is intended to
> follow the same locking rules as fsfs: reads never need to obtain a
> lock. Our current usage of sqlite3 does not seem to work that way.
> While there are no consistency problems, any of the calls to
> sqlite3_exec or sqlite3_step can return SQLITE_BUSY if another process
> has an exclusive (write) lock on the database. We do not check for
> SQLITE_BUSY in any of our calls to sqlite3_exec or sqlite3_step, nor
> do we install a busy handler with sqlite3_busy_handler or
> sqlite3_busy_timeout. Thus these get turned into Subversion errors.
>
> What should the policy be? Is it OK that mergeinfo reads can fail?
> Should we use a timeout? Try a fixed number of times to reread? Keep
> trying until we can read?
Here's a patch that adds a 10-second timeout (with sqlite's built-in
backoff-and-retry algorithm). It seems like that should be more than
enough. Any thoughts?
[[[
For the mergeinfo database, ask sqlite3 to retry for up to ten seconds
any query that fails to get a lock.
* subversion/libsvn_fs_util/mergeinfo-sqlite-index.c
(open_db): Call sqlite3_busy_timeout immediately after opening
the database.
]]]
--
David Glasser | glasser_at_mit.edu | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 9 21:27:40 2007