We have a system that uses SQL Server 2008 in tandem with MongoDB, using the latter for a lot of ad-hoc reporting features. They don’t intersect much, but there are one or two places where they do actually need to work together.
I was always slightly concerned about the transactional implications but figured it was not really a big problem if the application did the Mongo work first, and it technically isn’t that big of a problem if a transaction fails in the middle once in a while. But a recent bug came up that was causing them to consistently fail, and although I’ve fixed the bug that caused it, it made me realize just how much of a nuisance it is that I can’t just throw a distributed transaction over the whole unit of work.
Given one database that supports distributed transactions (SQL Server 2008) and another that doesn’t really support any ACID semantics (MongoDB), is there some way I can structure the application code so that a unit of work (“transaction”) either succeeds or gets rolled back in both databases?
Obviously I would have to use some extra columns/keys to track the status of the transaction – but what, and in what context?
What are your consistency requirements? Is it ok if ad-hoc reporting on the Mongo is not always entirely up-to-date?
If no, then I think you’re in for a hard time.
If yes, then I think I’d go for some transactional MSMQ along with the SQL Server, and then set up one (or more) services to update the Mongo by processing messages from the queue.