Reputation: 125
I need some inputs on practical use of BizTalk Atomic and Long Running transactions. I have read all the theory but not sure how the Atomic transaction will work if I am making multiple SQL calls and if some SQL call fails how the previously committed transaction/data will be rolled back.
Need some guide/link/pointer to understand the transaction better.
BizTalk version used: 2010
Upvotes: 1
Views: 971
Reputation: 11527
See this blog Indetail About Atomic Scope / Transactions in BizTalk Server
In particular:
Please note that, the scope of BizTalk with respect to Atomic Transaction is till BizTalk Server Message Box only. Please consider this before you decide to use Atomic scope.
So regarding the multiple SQL transactions, I don't think you can do it that way with an Atomic shape unless you aren't dependent on the results of the first SQL call. If you want a single SQL transaction that can be rolled back, you are better of doing that in a stored procedure that BizTalk calls.
About the only time I've used Atomic scopes is when having to call a Pipeline from inside an Orchestration or calling BRE.
Upvotes: 1
Reputation: 508
Main difference is that orchestration will never be persisted during Atomic transaction even on sending data to message box - everything will be made in one transaction established by DTC. Actually message isn't really sent to MB if you sent it from Atomic transaction - it's written but not committed. Another difference is that Atomic transaction automatically rolls back everything inside in case of failure. So you can be sure all the action inside are done at once or not at all.
In reality Atomic transaction has too many limitations and quite exotic way to do things in BizTalk. I've implemented a lot of solutions with BizTalk but never used Atomic transaction so far. But I use a lot Long Running to force orchestration persist some intermediate state (happens at the end of any transaction scope) or define compensation actions.
Upvotes: 1