> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: dinsdag 18 oktober 2011 12:10
> To: dev_at_subversion.apache.org
> Cc: commits_at_subversion.apache.org
> Subject: Re: svn commit: r1185242 -
> /subversion/trunk/subversion/libsvn_subr/sqlite.c
>
> rhuijben_at_apache.org writes:
>
> > Author: rhuijben
> > Date: Mon Oct 17 15:13:35 2011
> > New Revision: 1185242
> >
> > URL: http://svn.apache.org/viewvc?rev=1185242&view=rev
> > Log:
> > Remove the SQLITE_OPEN_SHAREDCACHE flag from opening SQLite
> databases.
> > VisualSVN and AnkhSVN users are reporting errors caused by the
> limitations of
> > the shared caching in SQLite.
> >
> > The current implementation temporarily doesn't allow certain operations
> that
> > are allowed concurrently if the usual via-file sharing is used. Until
this is
> > fixed in SQLite I think we should stop using this flag.
> > The common errors are 'database table is locked' and 'schema has
> changed'.
> >
> > VisualSVN already disabled this flag in their build (reported by Ivan)
and I
> > will have to do the same thing in SharpSvn and as far as I know this are
> > currently the two most prominent multithreaded subversion library users
> > that would benefit if this flag always worked correctly.
>
> It also affects every multithreaded Unix server when accessing the
> rep-cache db. Does this affect the performance?
It affects performance, but in these cases not in a measurable way. There is
less thread synchronization as there is no shared cache and for the simple
tables for rep-sharing the filesystem cache has far more impact than the
local caching.
The only case where this really made a measurable difference was when we had
several separate access baton sets that opened the same wc.db.
(When we just switched to wc.db per directory an 'svn update' used 3 or 4
separate access baton sets to the same working copy at the same time and
switched operations between them)
Most of the optimizations used with the shared cache still work with the per
connection cache as that is what SQLite was designed for. (The relevant
changes are communicated via the db file)
Bert
Received on 2011-10-18 12:21:27 CEST