This is to prevent the issue with Object Slicing. With the previous
solution (where MDB*Transaction are normal objects), consider the
following code:
MDBRWTransaction txn = env.getRWTransaction();
//! Invalid: We explicitly break this move because it would be
//! unsafe:
// MDBROTransaction ro_txn(std::move(txn));
//! Valid, RW inherits from RO now, so we can bind an RO
//! reference to an RW transaction.
MDBROTransaction &ro_txn = txn;
//! Dangerous!!
MDBROTransaction ro_txn2(std::move(ro_txn));
The last move there breaks the semantics of the RW transaction which
is bound to the reference ro_txn. It looses its RW cursors, which
remain partly inside the txn instance. All kinds of weird and bad
things can happen here. For instance, the ro_txn2 would go out of
scope before the txn, calling the destructor MDBROTransaction
destructor (which defaults to commit instead of abort!) and only
freeing parts of the cursors. Only then the MDBRWTransaction
destructor is called, which will free the cursors which belong to
the RW transaction which has already been committed.
The only safe way to prevent Object Slicing in this scenario I
could come up with is to disallow moves of the objects altogether
and instead use unique_ptr as front for them. This also removes
an additional dynamic allocation per RW transaction (for the
cursor vector), since the address of that vector is now constant
over the lifetime of the transaction without indirection.
MDBRWTransaction now inherits from MDBROTransaction. Both
transaction types will free their cursors before aborting or
committing. In addition, transactions are now virtual classes.
The reason for this is that RW and RO transactions are handled
very differently in LMDB. Nevertheless, it is very useful to be
able to write read-only code in a way which also can use an RW
transaction. This saves code duplication or unnecessary templates.
Since the only methods which are reqiured to be virtual on
transactions for this to work are the destructor and the
abort/commit methods, the overhead should be neglegible.
This also comes in very handy when going forward to implement
nested transactions, because it is not possible to nest RO
transactions below RW transactions, exacerbating the issue
described above.
Fixes#7 en passant.
Martchus
Jonas Schäfer
bert hubert