Is SQL Server merge replication transaction-aware?

If I have two tables with a one-many relationship that are replicated using merge replication in the same publication, and on the subscriber I add a row to each i开发者_运维问答n a transaction, will SQL Server replication ensure that those rows are/are not applied at the server in a transaction, also?

Although I can't say for certain, there is convincing evidence that the answer is no.

First, the article on using logical records with merge replication states

By default, merge replication processes data changes on a row-by-row basis. In many circumstances this is appropriate, but for some applications, it is essential that related rows be processed as a unit. The logical records feature of merge replication allows you to define a relationship between related rows in different tables so that the rows are processed as a unit.

This seems to indicate that the method for grouping changes to multiple tables together is to define a (static) logical record mapping between them. If transactions could be used as an ad-hoc method for grouping changes, this ought to be unnecessary. Moreover, row-level conflict resolution doesn't conceptually fit with ad-hoc transactional grouping of changes.

Additionally, the definition of the MSmerge_contents table doesn't include any place where transaction information could be stored. There are columns for identity, which subscriber has modified the row, column-level change tracking and logical record tracking. There is also a promising sounding generation column, but a generation is all the changes between merges so that's right out as well.

In summary, all available evidence points toward changes made in a transaction not being applied transactionally when merging.