[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: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 15 Mar 2011 14:34:23 +0000

Philip Martin <philip.martin_at_wandisco.com> writes:

> Branko Čibej <brane_at_e-reka.si> writes:
>> The temporary table is:
>> * in a different database, so the read lock on it does not affect
>> the main wc-db;
>> * per-connection, so even the same process using a different
>> database connection will not even see that temporary table.
> OK, so the process is:
> - read lock on main database
> - write lock on temporary database
> - populate temporary table
> - release write lock
> - release read lock
> - read lock on temporary database
> - make callbacks
> - release read lock
> without the temporary table it could be:
> - read lock on main database
> - make callbacks
> - release lock
> What we gain is that the callback can modify the main database, because
> there is no read lock. It still can't modify it using any functions
> that require write access to the temporary database.
> What we lose is that the callback cannot call any "read-only" functions
> that use temporary tables because the step that requires a write lock
> will fail.

So with the temporary table approach the callback really has to use a
separate database connection to read/write the database from within the

However I think that is also the case if we were to avoid the table and
simply lock the main database; if just one connection was reused it
might be attempt to reuse an SQLite statement.

Received on 2011-03-15 15:34:57 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.