Hyrum K. Wright wrote:
> Greg Stein wrote:
>> Since you've already added sqlite, then you can simply go another
>> step: put the revprops in there. (I'd suggest as a separate dev effort
>> tho)
>
> That was my thought exactly (same with the fsfs locks storage, too). My only
> concerns are scalability and consistency on something like NFS. If we lose data
> from the rep-cache sqlite database, that doesn't impact the correctness of the
> repository. If something happens to revprops, it's a different story.
>
> Is there any reason to be concerned about using SQLite to store first class data
> in the repository?
To answer my own question (from http://www.sqlite.org/faq.html#q5):
SQLite uses reader/writer locks to control access to the database. (Under
Win95/98/ME which lacks support for reader/writer locks, a probabilistic
simulation is used instead.) But use caution: this locking mechanism might not
work correctly if the database file is kept on an NFS filesystem. This is
because fcntl() file locking is broken on many NFS implementations. You should
avoid putting SQLite database files on NFS if multiple processes might try to
access the file at the same time.
Now, we currently make less-than-perfect concurrency guarantees about revprop
editing anyway, so we may not have problems, but I can see this coming back to
bite us.
Then again, I may be worrying about nothing at all. :)
-Hyrum
Received on 2008-10-18 13:55:29 CEST