[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: A performance tip

From: <rassilon_at_lyra.org>
Date: 2003-01-23 19:49:07 CET

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

This is an archived mail posted to the Subversion Dev mailing list.