MDB_NOLOCK, как описано в mdb_env_open () apido c:
MDB_NOLOCK Не делать никакой блокировки. Если ожидается одновременный доступ, вызывающая сторона должна управлять всем параллельным доступом. Для правильной работы вызывающая сторона должна применять семантику одного записывающего и должна гарантировать, что никакие читатели не используют старые транзакции, пока записывающее устройство активно. Самый простой подход состоит в том, чтобы использовать эксклюзивную блокировку, чтобы никакие считыватели не могли быть активными вообще, когда начинающий писатель.
- Что если RW txnA намеревается изменить набор ключей, который не имеет общий ключ с другим набором ключей, который другой RW txnB намеревается изменить? Разве они не могут быть отправлены одновременно?
- Не является ли semanti c для одного автора расточительным для таких ситуаций? Поскольку один txn ожидает, пока предыдущий завершит sh, даже если они намерены работать в совершенно разных регионах в среде lmdb.
- В среде, открытой с помощью
MDB_NOLOCK
, что если клиентское приложение вычисляет в области доменов, что две транзакции записи предназначены для RW для взаимоисключающего набора ключей в любом месте среды lmdb, и в любом случае отправляет только такие транзакции одновременно? Что может go не так? - Может ли такая одновременная запись масштабироваться линейно с ядрами? Как RO TXNS делать? Учитывая, что приложение может управлять этими одновременными записями, как описано в 3.