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.
--
exitsts .not
exeunt hoall.
http://stefano.cossu.cc
