[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: wc_db performance

From: Branko ─îibej <brane_at_e-reka.si>
Date: Mon, 14 Mar 2011 22:41:37 +0100

On 14.03.2011 17:13, Stefan Sperling wrote:
> On Mon, Mar 14, 2011 at 05:05:39PM +0100, Stefan Sperling wrote:
>> The concern seems to be that invoking a notification callback could
>> attempt to modify DB state, correct? Which would deadlock if you invoke
>> the callback after starting a transaction to tweak changelist information
>> but before this transaction has been committed (i.e. the write lock has
>> been released)?
> Of course, the same problem happens when the notification callback
> does a *read* operation on the DB (because writers block readers --
> somehow this restriction is kinda hard to getting used to...)

The restriction that you may not invoke a callback from within a sqlite
transaction remains. That's what the temporary results tables are for --
they live outside transactions on the main wc-db.

Still, wherever possible, we shouldn't allow wc-db modifications from
within callbacks, except in a controlled manner through the wc-db API
itself (e.g., modifications could also be queued to a temporary table
whilst holding a read lock on wc-db; block writers, but lets other
readers continue, and writers need exclusive locks to the WC anyway).

-- Brane
Received on 2011-03-14 22:42:12 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.