[ZODB-Dev] bsddb3Storage locking

[Jeremy Hylton]

>>>>> "CRR" == Christian Robottom Reis <kiko@async.com.br> writes:

  CRR> I'm wondering, however, why, if a single process is accessing
  CRR> the Storage, we're using up so many locks on commit() -- IOW
  CRR> when we're actually writing out the file. (I don't know much
  CRR> about bsddb3 locking, so I guess this is kind of clueless to
  CRR> ask.) Is this normal? (reading through bsdstorage docs..)

I don't understand the details, but here's my vague recollection of
the problem.  (I'm the one who tried to commit a bunch of objects and
then forced Barry to at least mention the problem in the release notes
;-).

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
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.

Jeremy