Re: svn upgrade fails with database table is locked

On Mon, Aug 22, 2011 at 14:10, Markus Schaber <m.schaber_at_3s-software.com>wrote:

> Hi, Ivan,
>
> Von: Ivan Zhakov [mailto:ivan_at_visualsvn.com]
> > On Fri, Aug 19, 2011 at 16:33, Bert Huijben <bert_at_qqmail.nl> wrote:
> > >> -----Original Message-----
> > >> From: Markus Schaber [mailto:m.schaber_at_3s-software.com]
> > >> Sent: vrijdag 19 augustus 2011 14:22
> > >> To: dev_at_subversion.apache.org
> > >> Subject: svn upgrade fails with database table is locked
> > >>
> > >> Hi,
> > >>
> > >> I have a working copy which reliably fails to upgrade to SVN 1.7
> > >> format, using both the latest TortoiseSVN nightly build, and the
> > >> Collabnet svn.exe for 1.7 beta 3.
> > >>
> > >> Upgraded '.'
> > >> Upgraded 'Device'
> > >> Upgraded 'Device\Plc Logic'
> > >> Upgraded 'Device\Plc Logic\Application'
> > >> Upgraded 'Device\Plc Logic\Application\Library Manager'
> > >> svn: E200030: database table is locked
> > >> svn: E200030: database table is locked: NODES
> > >>
> > We experienced similar issue with "database table is locked" message in
> > VisualSVN and found that disabling SQLite shared cache fixes the problem.
> > In our case problem was appearing when background thread running svn
> > status on working copy and foreground thread performs read/write
> > operations on the same working copy.
>
> How do I disable SQLite shared cache programmatically via SharpSVN? And
> what's the impact?
>
We had to patch Subversion source code on build time to remove call to
function that enables shared cache in SQLite. SQLite shared cache seems to
be peformance optimization when same database accessed using different
connections. I believe Subversion uses few connection to database, so it
should be big performance degradation after disabling shared cache.

-- 
Ivan Zhakov