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

On Sun, May 21, 2017 at 1:51 AM, Howard Chu <[email protected]> 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 <[email protected]
>> <mailto:[email protected]>> 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#gac08cad5b0969
>> 25642ca359a6d6f0562a
>>     <http://www.lmdb.tech/doc/group__internal.html#gac08cad5b096
>> 925642ca359a6d6f0562a>
>>
>>             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 <
>> [email protected]
>>         <mailto:[email protected]>
>>         <mailto:[email protected] <mailto:[email protected]>>> wrote:
>>
>>             Thanks.
>>
>>             On Sat, May 20, 2017 at 6:29 PM, Klaus Malorny
>>         <[email protected] <mailto:[email protected]>
>>             <mailto:[email protected] <mailto:[email protected]
>> >>>
>>
>>         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/
>

Reply via email to