Mark Phippard wrote:
> On Mon, Oct 5, 2009 at 12:52 PM, Branko Cibej <brane_at_xbc.nu> wrote:
>
>
>> But anyway the question is irrelevant. If we manage to lock up the
>> server for tens of seconds because of a slightly larger-than-usual
>> commit, we need to fix it. This is pretty much on my plate right now,
>> but I'll ask around for help on understanding FSFS details.
>>
>
> Have you made any progress on this? It would seem worthwhile to get
> this fix into 1.6.6 if possible.
>
Nope, I got sidetracked by $REAL_JOB. And I doubt it will be a trivial
change that can be coded, tested, reviewed and generally banged on in 6
days in time for 1.6.6.
> I do not want to sidetrack you, but I did have a couple questions (for anyone).
>
> 1) Why do we need to open this database when reading the repository?
> Such as for a checkout? My understanding is that the only time the
> cache is needed is when we are writing to the database. We want to
> see if there is an existing representation for the same hash. So why
> should we care if this database is locked when someone is doing a
> checkout?
>
The rep-cache database gets opened deep within svn_fs_fs__open and
svn_fs_fs__create. We don't really have a way to distinguish between
open-for-read and open-for-write in svn_fs_open. I can't form an opinion
right now on whether that's a serious omission or not, but in any case
adding an open-mode would be a huge conceptional change, of the svn-2.0
kind, IMHO.
> 2) I assume we are holding the database open while the transaction is
> being committed for atomicity, but do we really need it here?
> Couldn't we just write the new rows to the table after the commit
> succeeds? If the rows are not written it just means that a future new
> rep would the same cache would not share it. In the grand scheme of
> things, that seems minor compared to the current behavior.
>
I'm looking at this alternative, yes. The other one is to do the inserts
in smaller transactions. I don't /think/ that merely opening the
database for read/write access should lock it up; according to all the
docs I've seen, SQLITE_BUSY is a consequence of the whole-table lock
that SQLite acquires for writes.
> If we solved #1, it would seem like #2 would not be an issue.
>
Or if we had a real(er) database, such as BDB ... :D
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2405161
Received on 2009-10-08 18:40:15 CEST