You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we can’t write tests for concurrent transactions since memoryengine acquires lock on Begin. We should allow creating memoryengine instance that doesn’t lock so that we can test ACID properties of concurrent (but not necessarily parallel) transactions.
Note that with #231 it would be possible to pass such option via context.Context.
This is actually pretty complicated, because that would basically force us to implement MVCC in the memoryengine, which by itself is a huge project.
The current memory engine provides the same guarantees as BoltDB or SQLite, which is one concurrent writer and multiple concurrent readers.
Is there something that you think is missing in the memoryengine?
It’s indeed hard for the general case, but the point is to be able to synchronously test concurrent transactions for cases like #243. Currently it should suffice to clone the underlying BTree on Begin and return an error on Commit if another transaction modified the tree. This should (mostly) match the behavior in BadgerDB.
Perhaps this could also be a separate implementation in a new testengine package.
Currently we can’t write tests for concurrent transactions since
memoryengine
acquires lock onBegin
. We should allow creating memoryengine instance that doesn’t lock so that we can test ACID properties of concurrent (but not necessarily parallel) transactions.Note that with #231 it would be possible to pass such option via
context.Context
.Related: #243
The text was updated successfully, but these errors were encountered: