7

MongoDB is to me a great database. However there are cases where I really need atomic multi-document transactions. For example to transfer things (like money or reputation) between accounts and this needs to either succeed completely or fail completely.

I wonder if it would be possible to interact with MongoDB through a library implementing the MultiVersion Concurrency Control pattern.

How bad would it be concerning performances? Would it be possible and profitable to use a hybrid approach, using the 'mongo-mvcc' library only when necessary and the traditional db connection when working only on a single document or would this break the mvcc stuff ?

Improve this question
2
  • Have you tried the atomic flag? Commented May 12, 2011 at 22:13
  • @Jimmy Sawczuk: this only works for a single document Commented May 12, 2011 at 22:17

6 Answers 6

Reset to default
7

The simplest way is to use locks (two-phase commit), although this is not very efficient in some cases. For higher concurrency some kind of MVCC can be implemented on the top of Mongo. This article provides a good description:

http://highlyscalable.wordpress.com/2012/01/07/mvcc-transactions-key-value/

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

6
+25

Money transaction can be implemented via two-phase commit : http://www.mongodb.org/display/DOCS/two-phase+commit

Improve this answer

1 Comment

Consider improving your post since your answer is essentially a link. See: Are answers that just contain links elsewhere really “good answers”? and Why is linking bad?
5

There is an implementation of MVCC on MongoDB available now on GitHub:

https://github.com/igd-geo/mongomvcc

Improve this answer

Comments

2

MongoDB isn't really designed to work with transactions. There is a really good discussion of how you might be able to implement this over at: http://kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/

Improve this answer

1 Comment

thanks for the link. However the article says: "Certainly, if we needed to literally debit one account and credit another in the same operation, or if we wanted rollback, we’d need full-fledged transactions." This was exactly my question...
0

You could create a versions collection and have a document for the last committed version.

Atomically update this document with the Read Timestamp (rts) which is not a time based timestamp but a monotonically increasing number when your application code has read a document from a collection.

Before you update a collection, fetch this versions collection document and check if there is a read timestamp below your current transaction, if there is, abort the read or write.

Update the versions document when you want to "publish" with a lastCommit the version of a record and cause it to be visible.

You should only "see" transactions data that are less than or equal to the last committed transaction number.

I implemented MVCC in Java in this repository.

Improve this answer

Comments

-1

Well when you need real TRANSACTIONS you use RDBMS which are designed to support them :) NoSQLs are faster and more scalable mainly because they don't support transactions.

If you need both maybe it's a good idea to have transactional layer to support transactions and NoSQL layer for other purposes? In some cases it shouldn't be difficult to create a hybrid system using for example MongoDB and PostgreSQL

Improve this answer

4 Comments

In theory, it's not so hard to create system with hybrid persistence, but I guess in practice it is quite a different story...
From the couchdb technical overwiew it's written: "If the storage engine is enhanced to allow multi-document update transactions, it is possible to perform Subversion-like 'all or nothing' atomic commits when replicating with an upstream server [...]". I would say that NoSQL engines may drop multi-document transactions, but it's not a requirement...
There are also two open tickets for MongoDB, asking for multi-document transactions: jira.mongodb.org/browse/SERVER-2804 and: jira.mongodb.org/browse/SERVER-2172
It may be a requirement of RDBMSs to support transactions, but not every DBMS that supports transactions is relational.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.