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