Previously the destroy call was called inside commit and rollback. This has since been removed since #53, since the ResourceAcquire<DBTransaction> already called destroy and it was unnecessary to call destroy twice.
However we discovered in the EFS (https://github.com/MatrixAI/js-encryptedfs/pull/74#issuecomment-1221833309), a dangling/floating promise could still have a reference to the transaction and end up trying to do a get on a transaction that is already committed. This ends up with the C++ code throwing a TRANSACTION_COMMITTED exception. This is not caught on the JS side because it was not expected to happen.
We are relying on the @ready decorator to protect the get methods and other methods if they are called when the transaction is already destroyed. But it does appear that there can be time between commit/rollback and destruction because these are separate functions.
We could make commit/rollback the equivalent of a destruction by applying the commit/rollback code inside the destroy call. And make destroy have a type: 'commit' | 'rollback' union. This way DBTransaction.commit and DBTransaction.rollback is just forwarding the call to the destroy.
This can simplify our transaction lifecycle, and ensure that methods cannot be called when a commit/destroy is being called, because this means it's in the process of being destroyed. It could also mean that we can use the ready blocking that we found we couldn't do when attempting to fix the dangling transactions during db.stop().
Additional context
53 - waiting for commit/rollback when db.stop() is destroying dangling transactions
Specification
Previously the
destroycall was called insidecommitandrollback. This has since been removed since #53, since theResourceAcquire<DBTransaction>already calleddestroyand it was unnecessary to calldestroytwice.However we discovered in the EFS (https://github.com/MatrixAI/js-encryptedfs/pull/74#issuecomment-1221833309), a dangling/floating promise could still have a reference to the transaction and end up trying to do a
geton a transaction that is already committed. This ends up with the C++ code throwing aTRANSACTION_COMMITTEDexception. This is not caught on the JS side because it was not expected to happen.We are relying on the
@readydecorator to protect thegetmethods and other methods if they are called when the transaction is already destroyed. But it does appear that there can be time between commit/rollback and destruction because these are separate functions.We could make commit/rollback the equivalent of a destruction by applying the commit/rollback code inside the
destroycall. And makedestroyhave atype: 'commit' | 'rollback'union. This wayDBTransaction.commitandDBTransaction.rollbackis just forwarding the call to thedestroy.This can simplify our transaction lifecycle, and ensure that methods cannot be called when a commit/destroy is being called, because this means it's in the process of being destroyed. It could also mean that we can use the ready blocking that we found we couldn't do when attempting to fix the dangling transactions during
db.stop().Additional context
53 - waiting for commit/rollback when
db.stop()is destroying dangling transactionsTasks