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 <elend...@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 <h...@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 <h...@symas.com >>> <mailto:h...@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#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 < >>> elend...@gmail.com >>> <mailto:elend...@gmail.com> >>> <mailto:elend...@gmail.com <mailto:elend...@gmail.com>>> wrote: >>> >>> Thanks. >>> >>> On Sat, May 20, 2017 at 6:29 PM, Klaus Malorny >>> <klaus.malo...@knipp.de <mailto:klaus.malo...@knipp.de> >>> <mailto:klaus.malo...@knipp.de <mailto: >>> klaus.malo...@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/ >> > >
