[Date Prev][Date Next]
Re: LMDB transcations - how
- To: Christian Sell <email@example.com>, "OpenLDAP, Technical" <firstname.lastname@example.org>
- Subject: Re: LMDB transcations - how
- From: Howard Chu <email@example.com>
- Date: Fri, 11 Dec 2015 16:17:44 +0000
- In-reply-to: <672190708.298548.1449791726795.JavaMail.firstname.lastname@example.org>
- References: <672190708.298548.1449791726795.JavaMail.email@example.com>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 SeaMonkey/2.42a1
Christian Sell wrote:
I am looking for advice about how to best handle LMDB transactions and to avoid
pitfalls. Our application is multi-threaded, with several threads accessing
persistent data in a streaming fashion (reading lots of data sequentially). I am
also not sure that it will be practical to stick with one transaction per
thread, so MDB_NOTLS may be needed.
Using more than one transaction per thread generally means You're Doing It
Wrong. A transaction's purpose is to isolate work from other concurrent work.
By definition, a single thread can only do one thing at a time, so there
cannot be any concurrency for two transactions in the same thread.
In this scenario, there are few "natural" transaction boundaries, which is why I
am asking when or how often a commit/abort (or reset/renew) should be issued.
A transaction is an Atomic, Isolated snapshot of the database. If you don't
need multiple DB accesses to have a single atomic view of things, then split
up the transactions to whatever granularity you need.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/