Berkeley DB：哈希访问方法的锁对象数量
该页面说“对于哈希访问方法，您只需要一个锁对象”。
http://www.oracle.com/technology/ Documentation/berkeley-db/db/programmer_reference/lock_max.html
这是否意味着访问数据库的所有进程/线程都会尝试锁定同一个锁对象？这不会导致非常高的锁争用吗？
谢谢！
——米奇
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_reference/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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这里描述的是如何计算应用程序所需的锁对象数量，尽管默认的锁对象配置（1000）通常就足够了。它描述了给定的单个数据访问操作需要多少个锁对象，以便您可以将其乘以并发数据访问操作的数量并适当配置锁对象的数量。这并不是真正谈论锁争用。
对于HASH访问方法，给定的键值直接映射到哈希桶。只需查看（并锁定）一页即可获取数据。这与Btree（需要遍历内部索引节点才能获取数据）和Queue（需要锁定每条记录以及该记录所在的页）不同。
在最近的版本中，我们实际上消除了一些不需要的锁，因此一种更简单的放置方式是：
每个数据库操作都需要
基本上，每次数据访问通常使用 2-3 个锁对象。事务会累积锁对象直到事务完成，因此如果应用程序中的事务通常访问 10 条记录，则该事务将需要 20-30 个锁对象。如果应用程序中最多可以有 10 个并发线程，那么您需要将系统配置为拥有大约 300 个锁对象。配置比您需要的更多总是更好，这样您就不会耗尽并且过度分配锁对象的内存开销最小（它们是小型结构）。
我希望这有帮助。
戴夫
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
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