[email protected] wrote: > On 27/05/16 15:11, "Hallvard Breien Furuseth" <[email protected]> > wrote: > >> This works as intended. Each transaction is atomic, and shall see >> neither DBIs nor data which were committed after the transaction began. >> Cross-txn mdb_dbi_open() is in any case hairy to get right, we screwed >> it up several times before arriving at the now-obvious semantics. >> > > It is fine that newly opened database handles shall not be seen by > other transactions as long the transaction runs.. But once the > transaction which opened the handle is committed it should be valid > for any other transaction.
It should be valid for any other transaction *that started after the opening transaction committed.* This is the nature of transactions, they are fully isolated from each other. > This would greatly simplify lazy database > opening of a multithreaded application. Allowing existing transactions to use the DBIs would break transaction isolation. That is a non-starter. > The suggested patch does exactly implement that behaviour. I believe > it does not break anything. Isolation must be guaranteed for the data > but not necessarily for the database handles. Wrong. A database handle essentially points to data. Exposing that data to a transaction that was opened before that handle's transaction was committed *does* break isolation. Violating the ACID guarantees of LMDB's transaction system is Not allowed. > >> An application can open and cache its DBIs in a separate startup >> transaction, then commit it and start new transactions. > > Yes this would be a simple approach to get around that problem. But I > do not like it as with each opened database the overhead increases > especially if not using my suggested improvements in ITS#8430. You are saying you don't like ACID transactions. If that's the case, LMDB is not for you. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
