Is there a downside to always use `instant: true` on Inserts/Updates/Remove?

[a4xrbj1]

Please correct me if I'm wrong but isn't the MongoDb 4.x feature of multi-document transactions implemented in such a way that it always instantly inserts/updates/removes a doc but still until a commit can roll the multi transactions back?

If so, what is the common best practice with this package? Is it ok to always use instant: true with any insert/update/remove?

What would be the downside of doing so? Our app has over 1200 functions on the server side and we're in the process of implementing this package and experienced crashes when we noticed that our app was relying on an inserted/updated doc within the same transactions steps.

Thanks in advance and great package so far!

[JackAdams]

Hi Andreas,

Thanks for the kind words. Now, before going too far down the road with this package, there are some things to consider:

1) It doesn't use MongoDB 4.x multi-document transactions under the hood. I wrote this package 5.5 years ago because Mongo didn't have those at the time. 2) This package operates at the app level; transactions are WAY more robust at the database level and, as of MongoDB 4.x, these are available to us. 3) This package has a few advantages over the native Mongo implementation

• queryable record of transactions in the transactions collection (that's the name of the collection in Mongo; tx.Transactions is the related Meteor collection)
• a pretty simple API to work with
• the ability to add undo/redo for users with another package 4) This package has some disadvantages when compared with Mongo's native implementation
• data integrity (it's better than no transactions package, but data integrity is not so guaranteed as it would be with the transactions done at the database level)
• Mongo API support is extremely limited ($set, $unset, $addToSet, $pull and $inc -- I think that's about it)
• The write volume of this package is very high (more than twice as many writes to the db to achieve the same thing using the native implementation); in Meteor apps, where write volume matters for scaling purposes, this is a serious consideration.

If I was writing this package now I'd either: 1) Not write it at all and use the native Mongo multi-document transactions 2) Write a light wrapper package around the native Mongo implementation to give me the API I wanted, along with a record of transactions in a queryable collection

Because my apps are so heavily dependent on this package, it's still maintained and will be for the foreseeable future. I do, however, recommend considering carefully whether you want to invest time in using this package or whether you want to go for the native Mongo 4.x multi-document transactions.

Finally, to actually answer your question with regards to instant: true, my rule of thumb is to only use it when I have to. It is easier to recover from a crash during a transaction (and the data is left in a less corrupt state in the interim) if you haven't been using instant: true.

[a4xrbj1]

Thanks for the time taken to answer my question.

We can’t use MongoDb’s native feature of multi transactions as Meteor isn’t supporting it. We haven’t found a way to make it work, you will find detailed threads in the official Meteor forum.

As we do need the ability to rollback multi transactions in our app, we use your package which is still a godsend despite being 5.5 years old.

I think I read somewhere else that you also only need those transaction docs for less than 5 minutes, same would be for us so I hope you will install a parameter that allows to purge those old docs automatically as per each users own need (there are two closed issues on this but it seems it’s not implemented as we speak).

You’re correct that it’s safer to use instant only where needed but we don’t expect many errors where a roll back is required (as our quality will hopefully further improve there will be less and less errors happening).

On 2 Feb 2019, at 14:58, Brent Abrahams notifications@github.com wrote:

Hi Andreas,

Thanks for the kind words. Now, before going too far down the road with this package, there are some things to consider:

It doesn't use MongoDB 4.x multi-document transactions under the hood. It wrote this package 5.5 years ago because Mongo didn't have those at the time. This package operates at the app level; transactions are WAY more robust at the database level and, as of MongoDB 4.x, these are available to us. This package has a few advantages over the native Mongo implementation queryable record of transactions in the transactions collection (name of collection in Mongo; tx.Transactions is the related Meteor collection) a pretty simple API to work with the ability to add undo/redo for users with another package This package has some disadvantages when compared with Mongo's native implementation data integrity (it's better than no transactions package, but it's not as guaranteed as it can be when the transaction is done at the database level) Mongo API support is extremely limited ($set, $unset, $addToSet, $pull and $inc -- I think that's about it) The write volume of this package is very high (more than twice as many writes to the db to achieve the same thing using the native implementation); in Meteor apps, where write volume matters for scaling purposes, this is a serious consideration. If I was writing this package now I'd either:

Not write it at all and use the native Mongo multi-document transactions Write a light wrapper package around the native Mongo implementation to give me the API I wanted, along with a record of transactions in a queryable collection Because my apps are so heavily dependent on this package, it's still maintained and will be for the foreseeable future. I do recommend considering carefully whether you want to invest time in using this package or whether you want to go for the native Mongo 4.x multi-document transactions.

To finally answer your question with regards to instant: true, my rule of thumb is to only use it when I have to. It is easier to recover from a crash during a transaction (and the data is left in a less corrupt state in the interim) if you haven't been using instant: true.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.