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 ?

Community
  • 1
  • 1
ascobol
  • 7,554
  • 7
  • 49
  • 70

6 Answers6

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/

user1128016
  • 1,438
  • 3
  • 16
  • 17
6

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

fun_vit
  • 384
  • 1
  • 3
  • 12
  • 3
    Consider improving your post since your answer is essentially a link. See: [Are answers that just contain links elsewhere really “good answers”?](http://meta.stackexchange.com/q/8231/156620) and [Why is linking bad?](http://meta.stackexchange.com/q/7515/156620) –  Jul 05 '11 at 04:28
5

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

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

Thorsten Reitz
  • 51
  • 1
  • 1
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/

Leonard Garvey
  • 1,517
  • 12
  • 8
  • 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... – ascobol May 13 '11 at 14:07
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.

Samuel Squire
  • 127
  • 3
  • 13
-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

Daimon
  • 3,703
  • 2
  • 28
  • 30
  • In theory, it's not so hard to create system with hybrid persistence, but I guess in practice it is quite a different story... – driushkin Jul 04 '11 at 21:15
  • 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... – ascobol Jul 07 '11 at 13:21
  • There are also two open tickets for MongoDB, asking for multi-document transactions: https://jira.mongodb.org/browse/SERVER-2804 and: https://jira.mongodb.org/browse/SERVER-2172 – ascobol Jul 07 '11 at 13:25
  • It may be a requirement of RDBMSs to support transactions, but not every DBMS that supports transactions is relational. – dan_waterworth Jan 20 '12 at 15:31