We have a system that uses SQL Server 2008 in tandem with MongoDB, using the latter for many special reporting functions. They don’t intersect a lot, but there are one or two places where they really need to work together.
I was always a little worried about the transactional consequences, but decided that this is not a very big problem if the application first performed Mongo work, and technically it is not so much for the problem if the transaction fails in the middle once at a time. But a new error occurred, due to which they constantly failed, and although I corrected the error that caused it, it made me realize how much this is due to the fact that I can’t just throw out a distributed transaction over a whole unit of work.
Given one database that supports distributed transactions (SQL Server 2008) and another that does not actually support any ACID semantics (MongoDB), you can somehow structure the application code so that the unit of work ("transaction")) is either successful, or rolled back in both databases?
Obviously, I would have to use additional columns / keys to track the status of the transaction, but what and in what context?
source
share