The smaller our BDB transactions are the better off our datastore will
be for scalability. As far as I know, BDB doesn't let us get away with
doing dirty reads (no read lock was acquired) on known non-changeable
data. BDB also doesn't do lock escalation. I don't recall whether or not
BDB supports row locks or not. It might only support page locks. If
that's the case the smaller our BDB transactions the less time we hold
read locks open that prevent writing threads from getting about their
business of creating new Subversion transactions (or whatever).
FYI,
Bill
From: cmpilato@collab.net [mailto:cmpilato@collab.net]
Justin Erenkrantz jerenkrantz@apache.org writes:
I'm starting to think some of our transactions are a bit too
fine-grained and we're getting killed by the fact that they are
ridiculously expensive in BDB.
C-Mike? -- justin
I don't think we're getting killed by anything, or that
transactions are ridiculously expensive. :-)
Yeah, we make heavy use of BDB transactions, and we make no
attempt to group operations into a single transaction. But
I'm not thrilled about the alternatives. With ra-dav opening
and closing the database once-per-operation (practically), we
would have to expose the database transaction layer through
the libsvn_fs interface. I suppose we could open a master
transaction at svn_fs_open() time, and attach it to the
svn_fs_t * object, then register a pool cleanup function that
closes the environment.
But that's starting to look a little yucky, and I'm not sure
how it affects our movement into different database backends.
Also, I'd like to know if there are operations in the FS
that depend on that granularity.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:09:43 2006