We’re exploring different approaches for communicating between two different SQL Server instances. One of the desired workflows is to send a message of some sort to the “remote” side requesting, let’s say, deletion of a record. When that system completes the deletion, it holds its transaction open and sends a response back to the initiator, who then deletes its corresponding record, commits its transaction, and then sends a message back to the “remote” side, telling it, finally, to commit the deletion on its side as well.
It’s a poor man’s approximation of two-phase commit. There’s a religious debate going on in the department as to whether SQL Server Service Broker can or can’t handle this type of scenario reasonably cleanly. Can anyone shed light on whether it can? Any experience in similar types of workflows? Is there a better mechanism I should be looking at to accomplish this, considering that the SQL Server instances are on separate, non-domain machines?
Edit: To clarify, we can’t use distributed transactions due to the fact that network security is both tight and somewhat arbitrary. We’re not allowed the configuration that would make that possible.
Unless I’m misunderstanding the requirements, I’d say it’s a perfect job for Service Broker. Service Broker frees you from the need of using distributed transactions and 2PC. What you do with Service Broker is reduce the problem to local transactions and transactional messaging between the servers.
In your particular case, one of the servers would delete its record and then (as part of the same transaction) send a message to the other server requesting deletion of the corresponding record. After enqueuing the message, the first server can commit the transaction and forget the whole thing without waiting for synchronization with the second server. Service Broker guarantees that once enqueuing of a message is committed, the message will be transactionally delivered to the destination, which can then delete its record as part of the same transaction in which it received the message, thus making sure the message processing and data changes are atomic.