[ZODB-Dev] bsddb3Storage locking

[Christian Robottom Reis]

On Fri, 18 May 2001, Jeremy Hylton wrote:

> The storage uses BerkeleyDB in transactional mode.  The DB
> implementation uses locking internally for each object that is udpated
> during a transaction.  There's no explicit use of locks as you seem to
> be thinking; the implementation doesn't use Python locks for each

No, I understand it's purely a DB issue.

> object.  Because these are DB locks, I suspect the subtransaction issue
> is irrelevant.  When a transaction commits, all the updates it
> performed, including those performed by committed subtransactions, are
> sent to the storage as part of the commit.  It is at this point that
> the storage runs out of DB locks and fails.

Well, the subtransaction issue _is_ rather irrelevant - the problem occurs
when committing large numbers of objects. So my question is more of a DB
question (though linked to ZODB's behaviour): why do we use up database
locks for single, non-concurrent, linear, writing? But of course the
answer is that locks are created regardless of being used; therefore
matching locks to the number of objects being written at one time is
essential. The release notes could state that, simply.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311