[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#8431) LMDB: Access newly opened database from another transaction

On Sat, May 28, 2016 at 11:18 AM, Howard Chu <hyc@symas.com> wrote:
> 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.

Not at all ACID is a must and something I very much appreciate about
LMDB! LMDB is definitely for me and I'm saying that after having spent
nearly one intensive year with LMDB!
So I like to thank you for the outstanding database.

> --
>   -- Howard Chu
>   CTO, Symas Corp.           http://www.symas.com
>   Director, Highland Sun     http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/