Greg Hudson <ghudson@MIT.EDU> writes:
> This is an interesting weakness of Berkeley DB relative to the
> filesystem as a storage tool for large data objects.
>
> We have separate reps and strings tables so that we can have a stable
> reference point for the representation while we build up a new string
> entry in several steps (specifically, during redeltification). If we
> didn't have separate tables, then the contents of a revision would
> always be valid, and we wouldn't need to lock around read operations.
>
> In the filesystem, you can build up a file in several steps and rename
> it into place (at least on Unix, and I think also on Windows), without
> changing the reference point.
I didn't understand this.
We do change the file in safe steps behind a static reference point --
as long as we use some sort of locking mechanism (such as BDB
transactions) to ensure that the old reference point still has
something to refer to for as long as it's being used. That's
inevitable; regular filesystems are doing their own transactioning
behind the scenes, too.
> If we
> didn't have separate tables, then the contents of a revision would
> always be valid, and we wouldn't need to lock around read operations.
I don't think it has anything to do with separate tables or not. We
need the lock (or transaction) around read operations because we
change the way the data is represented. We could do that just as
easily if it were all in one table; and we could avoid doing it, while
still using separate tables.
If we wanted to, we could store large data objects in BDB and simply
agree never to change their representations; then BDB would behave
just like a filesystem.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 21 06:30:47 2003