The serializable consistency model discussed earlier creates a somewhat more restrictive locking model than is the case for a normal MongoDB database. Since each version is deterministically dependent on the previous version, only one version can be created simultaneously. Except in the case of bulk load or ignored collections – discussed below – this has the effect of a single database-wide exclusive lock during update, delete, or insert operations.

ProvenDB also implements collection level shared read locks, which prevent changes to a collection during Merkle tree construction. This may inhibit update, delete, or insert operations when proofs are being calculated or validated.

Rollbacks

Statement level rollbacks are somewhat more complete than is the case in transactional MongoDB. In MongoDB, if a statement fails midstream, any changes to that point will take effect. In ProvenDB if a statement fails midstream, the version in progress is removed with the result that any in-progress changes are also removed.

ProvenDB rollbacks are automatic. However, a rollback command is provided which will cause any currently executing insert, update or delete operation to be aborted and rollbacked.