Wrong rollback implementation

[Guseyn]

As I can see here, you use "old model" for restoring consistency of db in the rollback transaction. It's wrong, you shouldn't implement rollback that way because Mongo does not provide atomic operations on multiple documents or collections.

For example, you want to transfer funds from account A to account B and in the middle of this transaction something bad happened. Let's say account A is changed, but an operation on B account has failed. And now you want to restore account A using "old model" , but what if at the same time account A is being used in another transaction that finishes before the rollback transaction, that means that "old model" is not actual any more.

You have to use Two Phase Commits with some kind of reversed(opposite) values in the fields of the operations in the rollback transaction that restore the consistency of the db.

[topperblues]

Hi, you are right about the atomicity of operations. I hope that in next release we can adapt the restore algorithm in order to guarantee the atomicity of the operations, for now we assume that the plugin does not guarantee atomicity. It works well in situations such as order management, invoices, products. For example you create a new order and add to it a list of products, something went wrong with order payment and you need to delete order and linked products.

This plugin, in the current implementation, is useful to manage (and revert) all situation in which involved documents are not used by other function at the same time. This could seem a huge limitation but in reality there are many cases where we need a transactional (sequential) behavior of the operations and we can do without the atomic nature of the operations.

Thanks for the suggestion, regards.