Howard Chu wrote

"Just follow the recommendation to open all handles at the beginning of the program."

But what if I have lots of named databases like maybe 10000 or more. Wouldn't this be expensive.

I am developing a MongoDB like database (similar in query and update syntax) around LMDB.
The thing is I have some enhancements on my own like the ability to generate update queries
from within an ongoing update.

So in a multi threaded environment, if the name of a named dbi is generated from within a write
transaction (thread1) and proceeds to mdb_dbi_open it only to find that another read transaction
(thread 2) just opened the same named dbi after the write-txn of thread 1 started, the prospect of
mdb_dbi_open the same named dbi for thread 1 is lost forever.

On Sun, May 21, 2017 at 3:00 AM, Muhammed Muneer <elendilm@gmail.com> wrote:

My bad.
Didn't think it that way.
Thanks for the info.

On Sun, May 21, 2017 at 1:51 AM, Howard Chu <hyc@symas.com> wrote:
Muhammed Muneer wrote:

Thanks for clarifying.
I did get the impression but there was some part of it where I thought the doc
was not clear enough.

It is a fundamental principle of ACID transactions. The "I" in ACID stands for Isolation. That means nothing that changes elsewhere, while a transaction is underway, can affect that particular transaction. Since we already document that LMDB is a full ACID DB engine, none of this should require any further explanation.

Thanks anyway.

On Sat, May 20, 2017 at 10:46 PM, Howard Chu <hyc@symas.com
<mailto:hyc@symas.com>> wrote:

Muhammed Muneer wrote:

Is the following valid.

1) Read transaction 1 is started
2) Read transaction 2 is started and calls mdb_dbi_open and commits
3) Read transaction 1 uses the handle from (2)

Please learn how to read. The doc says more than you quoted before, and it
already quite explicitly defines its properties:

http://www.lmdb.tech/doc/group__internal.html#gac08cad5b096925642ca359a6d6f0562a
<http://www.lmdb.tech/doc/group__internal.html#gac08cad5b096925642ca359a6d6f0562a>

The database handle will be private to the current transaction
until the transaction is successfully committed. If the transaction is
aborted the handle will be closed automatically. After a successful commit
the handle will reside in the shared environment, and may be used by other
transactions.

In your question above, transaction 1 is not after transaction 2 therefore
it cannot use the handle that transaction 2 commits.

The handle does not exist in the shared environment until after its
opening transaction commits. If it doesn't exist in the shared environment
when a transaction begins, then it is not visible or valid in that
particular transaction.

Just follow the recommendation to open all handles at the beginning of the
program.

On Sat, May 20, 2017 at 6:46 PM, Muhammed Muneer <elendilm@gmail.com
<mailto:elendilm@gmail.com>
<mailto:elendilm@gmail.com <mailto:elendilm@gmail.com>>> wrote:

Thanks.

On Sat, May 20, 2017 at 6:29 PM, Klaus Malorny
<Klaus.Malorny@knipp.de <mailto:Klaus.Malorny@knipp.de>
<mailto:Klaus.Malorny@knipp.de <mailto:Klaus.Malorny@knipp.de>>>

wrote:

On 5/20/17 2:02 PM, Muhammed Muneer wrote:

So when the doc says

* The database handle will be private to the current
transaction until
* the transaction is successfully committed.

"the handle being private" only refers to the first
mdb_dbi_open.
Once this transaction is committed, one doesn't have to
call this
again in subsequent concurrent transactions and can use
this handle.
And then this handle won't be private at all.

Did I get it right?

Yes. I do this exactly that way as part of my initial setup of my
application. Once the transaction is committed, I use the returned
handles setup from whatever thread that needs to access the
respective
database. I never call mdb_dbi_open again after the setup.

Regards,

Klaus

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/