Muhammed Muneer wrote:
Hallvard wrote
"With threads 1 and 2 coexisting? When thread 2 called mdb_dbi_open(), thread 1's prospect of using mdb_dbi_open() at all was lost."
Yeah with both coexisting. Thats what I thought.
@Klaus
Yeah. I know there can be only one write transactions. I was talking about 1 write and 1 or more read transactions. It is not as if I am first looking to open dbi in the read transaction. It is because I can't guarantee whether another read transaction will start and will attempt to open the same named dbi when a write is in progress.
"And first looking in a read transaction whether a database exists and then creating it in a second write transaction is definitely a bad and risky programming style, as it carries an assumption from one transaction to the next, which is typically not valid."
That was not what I tried to do.
"you still have the option to combine all your logical databases into a big single database"
Its a workaround that I haven't thought about before. Hoping to avoid the extra complexity.
Is there any prospect of implementing mdb_dbi_open or mdb_db_open_immediate to put the dbi into the shared environment without waiting for txn commit. I learned earlier from Howard Chu that it is not a wanted phenomenon in ACID. But just in case, because otherwise (without opening all the dbi's in initialization) in a multi-threaded environment, the possibility to open a dbi on demand ending in failure goes up.
No. Transaction isolation is a fundamental feature, breaking isolation is not allowed.
If you want to use dbi_open in multiple threads then put it in your own wrapper function, protected by a mutex. Naturally you will also have to wrap dbi_close the same way. Note that even if you open and close on demand, you're going to have to configure maxdbs to the largest number that can possibly be open at once so there won't be much memory savings. All in all it's a stupid approach with more costs than benefits.