Usually, transactions occur on one database server: BEGIN TRANSACTION SELECT something FROM myTable UPDATE something IN myTable COMMIT A distributed transaction involves multiple servers: BEGIN TRANSACTION UPDATE amount = amount – 100 IN bankAccounts WHERE accountNr = 1 UPDATE amount = amount + 100 IN someRemoteDatabaseAtSomeOtherBank.bankAccounts WHERE accountNr = 2 COMMIT The difficulty comes from … Read more
I’d suggest to use a slightly altered variant of approach 2. Write into your database only, but in addition to the actual table writes, also write “events” into a special table within that same database; these event records would contain the aggregations you need. In the easiest way, you’d simply insert another entity e.g. mapped … Read more
On Two-Phase Commit Two phase commit does not guarantee that a distributed transaction can’t fail, but it does guarantee that it can’t fail silently without the TM being aware of it. In order for B to report the transaction as being ready to commit, B must have the transaction in persistent storage (i.e. B must … Read more
No, they are not instructed to roll back because in the original poster’s scenario, some of the nodes have already committed. What happens is when the crashed node becomes available, the transaction coordinator tells it to commit again. Because the node responded positively in the “prepare” phase, it is required to be able to “commit”, … Read more
Found it, MSDTC on the remote server was a clone of the local server. From the Windows Application Events Log: Event Type: Error Event Source: MSDTC Event Category: CM Event ID: 4101 Date: 9/19/2011 Time: 1:32:59 PM User: N/A Computer: ASITESTSERVER Description: The local MS DTC detected that the MS DTC on ASICMSTEST has the … Read more