You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by rh...@apache.org on 2011/10/17 17:13:35 UTC
svn commit: r1185242 - /subversion/trunk/subversion/libsvn_subr/sqlite.c
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.
I enabled this flag during the development of Subversion 1.7 to speed up
the then common case of opening the same wc.db file multiple times.
Currently we don't open the same database multiple times from a single
codepath. Instead we share the connection handle properly.
* subversion/libsvn_subr/sqlite.c
(internal_open): Remove SQLITE_OPEN_SHAREDCACHE flag as noted above.
Modified:
subversion/trunk/subversion/libsvn_subr/sqlite.c
Modified: subversion/trunk/subversion/libsvn_subr/sqlite.c
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/sqlite.c?rev=1185242&r1=1185241&r2=1185242&view=diff
==============================================================================
--- subversion/trunk/subversion/libsvn_subr/sqlite.c (original)
+++ subversion/trunk/subversion/libsvn_subr/sqlite.c Mon Oct 17 15:13:35 2011
@@ -667,13 +667,6 @@ internal_open(sqlite3 **db3, const char
flags |= SQLITE_OPEN_NOMUTEX;
#endif
- /* SQLite 3.5 allows sharing cache instances, even in a multithreaded
- environment. This allows sharing cached data when we open a database
- more than once.
-
- OS X 10.7 doesn't support sqlite3_enable_shared_cache. */
- flags |= SQLITE_OPEN_SHAREDCACHE;
-
/* Open the database. Note that a handle is returned, even when an error
occurs (except for out-of-memory); thus, we can safely use it to
extract an error message and construct an svn_error_t. */
RE: svn commit: r1185242 - /subversion/trunk/subversion/libsvn_subr/sqlite.c
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: dinsdag 18 oktober 2011 12:10
> To: dev@subversion.apache.org
> Cc: commits@subversion.apache.org
> Subject: Re: svn commit: r1185242 -
> /subversion/trunk/subversion/libsvn_subr/sqlite.c
>
> rhuijben@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
Re: svn commit: r1185242 - /subversion/trunk/subversion/libsvn_subr/sqlite.c
Posted by Philip Martin <ph...@wandisco.com>.
rhuijben@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?
--
Philip
Re: svn commit: r1185242 - /subversion/trunk/subversion/libsvn_subr/sqlite.c
Posted by Philip Martin <ph...@wandisco.com>.
rhuijben@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?
--
Philip