Hello, I'd like to be able to know if a LMDB transaction is active, valid, dirty, read-only, etc.
From the documentation I read that such information is in mt_flags of the mdb_txn structure, which is opaque. I don't see any function exposing mt_flags. Is there any other way to read that information?
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. All LMDB users need to know is whether they have created a valid txn, and whether they want to abort it or commit it.
From the documentation I read that such information is in mt_flags of the mdb_txn structure, which is opaque. I don't see any function exposing mt_flags. Is there any other way to read that information?
No. Nor are the flag definitions public.
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.
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?
From the documentation I read that such information is in mt_flags of the mdb_txn structure, which is opaque. I don't see any function exposing mt_flags. Is there any other way to read that information?
No. Nor are the flag definitions public.
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.
I see. It looks like I need to keep some state variables to track the transaction state. I was hoping that I could reduce my code and possible pitfalls by querying the transaction state flags, which are authoritative, but it won't be too bad.
I'm interested about the design decision not to expose some of the state flags which seem quite safe and useful to me, though.
Thanks for the advice, Stefano
On 6/29/20 8:44 AM, Howard Chu wrote:
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.
openldap-technical@openldap.org
-
Howard Chu -
Stefano Cossu