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.