juerg.bircher@gmail.com wrote:
On 27/05/16 15:11, "Hallvard Breien Furuseth" h.b.furuseth@usit.uio.no 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.