On Tue, May 13, 2003 at 01:07:08AM +0200, Benjamin Pflugmann wrote:
>...
> Reading the source[2] suggests that accesses for different processes
> are supported, but are serialized with granularity on the database
> level (the whole file containing all tables), i.e. nobody could check
> out any project while someone else is importing a new Linux kernel. I
> presume BDB handles that better?
BDB allows for access from multiple process and threads, simultaneously. I'm
not sure at what level the locks are, but I thought I heard somebody say
"page level" which is going to be better than table-locks, but not as nice
as row-locks. And certainly hella-better than database-locks.
> Besides, according to its own benchmark, it is only really fast for
> huge transactions (25000 INSERTs), but significantly slower for single
> statements with syncs (I presume here, that the nosync option is not
> suitable for Subversion).
Depending upon the operation, nosync might be quite nice. I actually
mentioned that to cmpilato the other day. For example, we construct a
long-lived txn in the database during an 'svn update' and other operations.
There is no reason at all to synchronize those to the disk. If the server
crashes while doing an 'svn update', then no big deal. The long-lived stuff
is actually supposed to be transitory, but the architecture doesn't allow us
to be that transitory.
Any txns intended for a commit "should" be synchronized, but even then it
doesn't really matter. If the server crashes mid-commit, then the client can
just resubmit. The *only* time that you really want to sync to disk is
during the final stages of a commit.
[ well, there are probably some generated IDs that need to be synced, and
maybe a few other bits, but in the majority: most of the DB operations we
performed can be somewhat lossy ]
>...
> > Just thought someone doing the SQL port might be interested in
> > playing with this, either for prototyping or otherwise...
>
> HTH,
It sure did. Thanks.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 13 01:23:57 2003