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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 26 23:03:21 2004