Re: LMDB transcations - how

[Howard Chu <hyc@symas.com>]

Christian Sell wrote:
> Hello,
>
> 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/