Re: SQLite locking for WCNG on NFS

"C. Michael Pilato" <cmpilato_at_collab.net> writes:

> On 02/14/2012 05:41 AM, Philip Martin wrote:
>> A substantial performance improvement but at the cost of making write
>> operations block read operations. This would mean things like TSVN
>> would not be able to run status on a working copy while its checkout was
>> running.
>
> Just to clarify, by "checkout" here, you mean "checkout or update", yes? I
> ask because while checkout might be a relatively rare operation, we tend to
> assume that updates happen all the time. Just want to properly frame the
> scope of this blocking action.

Yes, I believe anything that writes to the database will exclude
readers. I don't know whether the blocking starts from the point the
database is opened for writing or from the first write itself.

The performance improvements affect other commands:

 - a recursive commit command goes from 38s to 1.5s
 - a recursive status command goes from 3.3s to 1.5s.

The status command appears to be influenced by some sort of NFS cache in
my setup and immediately repeating the command gives a shorter runtime,
in this case the time drops from 2.3s to 0.5s.

The commit harvester appears to be particularly transaction intensive.

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com