[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Locking design (was Re: svn commit: r9885 - trunk/notes)

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-05-27 01:39:10 CEST

Ben Collins-Sussman wrote:

>On Wed, 2004-05-26 at 14:56, Greg Hudson wrote:
>>On Wed, 2004-05-26 at 13:41, Ben Collins-Sussman wrote:
>>>> With no transaction-based consistency protection?
>>>Write to a tmpfile, then move it.
>>It's not *quite* that simple. If you and I are both trying to lock
>>(different) files at the same time, then we could run into a race. (You
>>read, I read, you write, I write, and your lock is omitted.) If the
>>tmpfile always has the same name and is opened with O_EXCL, then one of
>>us will fail to open the tmpfile, which means there would have to be a
>>retry loop.
>>Another non-DB technique would be to have a directory tree of the locked
>>files. That would scale better in some ways and would eliminate the
>>possibility of multiple people interfering with each other by locking
>>different files, but it would mean checking a to-be-committed
>>transaction against the lock table would be slower. (We could probably
>>use directory pruning techniques to make it pretty fast, though.)
>So we're faced with two choices here:
>1. create a locks-table API in svn_fs.h, have svn_repos.h use it.
> - this means one fs backend would use a BDB table, and the other fs
>backend would have to implement the table either using a flat-file or a
>'mirror' of locked repository paths in real filesystem space.
>2. create a locks-tabel API in svn_repos.h
> - libsvn_repos absolutely cannot depend on BDB, so it means that it
>would need to implement the table either with a flat-file or a mirror of
>locked repos paths in real filesystem space.
>Either way, it looks like the "non BDB" option is going to have to be
>implemented, and real energy will be spent making sure it's reasonably
>scalable. Given that, option #2 seems better to me, just because it's
>nice to have shared/factorized code. And if we plan to add other fs
>backends someday (like SQL), this option becomes even more attractive.
Or the third (correct) choice:

3. Put the lock/unlock APIs into the FS and let the FS implementation
worry about the details of lookup tables and such

/me walks away whistling...

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 27 01:39:37 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.