Berkeley DB: Number of lock objects for hash access method

This page says that "for the Hash access method, you only need a single lock object".

http://www.oracle.com/technology/documentation/berkeley-db/db/programmer_refer开发者_运维问答ence/lock_max.html

Does this mean that all the processes/threads that access the database will try to lock the same lock object? Doesn't it cause a very high lock contention?

Thanks!

--Michi

---

What it's describing here is how to calculate the number of lock objects required by your application, although the default lock object configuration (1000) is usually enough. It's describing how many lock objects a given single data access operation will require, so that you can multiply that times the number of concurrent data access operations and configure the number of lock objects appropriately. It's not really talking about lock contention.

For the HASH access method, a given key value maps directly to a hash bucket. There is only one page that needs to be looked at (and locked) in order to reach the data. This is different from Btree (which needs to traverse the internal index nodes in order to get to the data) and Queue (which needs to lock each record and the page that the record resides on).

In recent releases we've actually eliminated some locks that weren't required, so that a simpler way of putting it would be:

Each database operation is going to require

• One lock object for the page (Btree, Hash or Recno) or record (Queue) that is being accessed,
• plus One lock object for the meta data page,
• plus One lock object if a Btree page split is required,
• plus One lock object per page if Queue is being used

Basically, typically 2-3 lock objects per data access. Transactions accumulate lock objects until the transaction is complete, so if a transaction in your application typically accesses 10 records, that transaction will require 20-30 lock objects. If you can have up to 10 concurrent threads in your application, then you would need to configure your system to have about 300 lock objects. It's always better to configure more than you need so that you don't run out and the memory overhead of over-allocating lock objects is minimal (they are small structures).

I hope that helps.

Dave