Stefano Cossu wrote:
On 6/29/20 8:12 AM, Howard Chu wrote:
Stefano Cossu wrote:
Hello, I'd like to be able to know if a LMDB transaction is active, valid, dirty, read-only, etc.
Why? There is no valid reason for these details to be exposed to LMDB callers.
I am working on a library where functions use a (possibly write) transaction that is passed around several (possibly reentrant) functions. Some operations may start with a write transaction and reuse it for writing at multiple points, some others may start with a read transaction and may need to temporarily open a separate write transaction depending on some conditions.
I don't want to commit a write transaction until I am sure that all inter-dependent operations are completed successfully.
I thought about nested transactions, but I still need to know whether the starting txn is a write one and it is valid.
If this is not the right pattern to use with LMDB I'd like to know how otherwise I can keep arbitrarily deep call stacks atomic.
This sounds pretty messy indeed. The caller that creates a transaction is expected to know what operations it is going to perform on it, and thus when it is done using it.
All LMDB users need to
know is whether they have created a valid txn, and whether they want to abort it or commit it.
How do I know if a transaction is valid?
Always zero out the txn pointer immediately after calling abort or commit. Then if the txn pointer is non-NULL, it is valid.