RejectedSoftware Forums

Sign up

Vibe.d - mongo and transactions

Hello,
I came up to the point having to implement some transactions for my vibe.d app. If a user has paid with Paypal the product document has to be updated as well as the user document has to be updated and that has to be securely made with rollback mechanisms in case something goes wrong (database crash or..).

I am keep reading articles about mongodb and ACID operations and as always there is no clear opinion. Some say mongodb is powerful, makes life easier and there are always ways to do everything you need even if requires more programming effort or sacrifices speed and others say just use a relational db and never mongodb for transactions.

Does anybody has any advice on that?
Does the vibe.d driver has anything related to ACID operations that i m not aware of?
Would be a wise solution to use two databases together?
(I am a beginner to all this so not experienced with SQL databases, i started by using vibe.d and mongodb).
If yes is there any example i could follow?
Or is better to try and bring things down to document level, play with two phase commits and in general stay around mongodb's capabilities?

Thanks a lot

Re: Vibe.d - mongo and transactions

On Thu, 03 Jul 2014 09:47:31 GMT, Yiannis Tsirikoglou wrote:

Hello,
I came up to the point having to implement some transactions for my vibe.d app. If a user has paid with Paypal the product document has to be updated as well as the user document has to be updated and that has to be securely made with rollback mechanisms in case something goes wrong (database crash or..).

I'm not sure what your complete model looks like, but in the case of a paypal payment, it's always better to straight up use a "payment confirmations" collection, where you will input all the fields sent back by paypal IPN including your temporary checkout ID.

You must store this temporary ID in an array of both your user document and product documents with a datetime field, at the moment the user is sent to paypal for payment, and avoid sending the user to paypal for as long as the collections do not hold the IDs. You should then setup a timer that "cleans up" the temporary IDs that were not yet confirmed by paypal in the "payment confirmations" after every x days. If you need statistics, those IDs can be copied elsewhere too at that precise moment as incomplete orders.

The more advanced technique suggested by MongoDB would be a little complicated: http://docs.mongodb.org/manual/tutorial/perform-two-phase-commits/

Though if you don't forget to authentify paypal as the remote computer during the IPN confirmation (you need to confirm the IP), this should be as reliable a model as an SQL transaction imo.