5:33 p.m.
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?
8:12 a.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8:33 a.m.
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.
>
8:44 a.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9:22 a.m.
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
1004
days inactive
1004
days old
openldap-technical@openldap.org
4 comments
2 participants
participants (2)
-
Howard Chu -
Stefano Cossu