You must Sign In to post a response.
Category: BizTalk
#668875
Atomic transaction should be used for the fast and simple procedures. The data before Atomic transaction is persisted on the disk, it is not persisted inside transaction regardless of operations inside. Atomic transaction is quick that's why it does not damage the total reliability. You can mention that Atomic transaction Timeout property by default set up to 60 sec, but not for the LongRunning transaction. Moreover only the Atomic transaction has the Property the Retry because it makes sense to automatically retry only the short process not the long one.
The likelihood of the system crash is bigger in the durations of hours and days than in seconds. That's why data inside LongRunning transaction persisted to disk. That's why the orchestration data used in the Long- Running transaction must be serializable. That's why the LongRunning transaction theoretically slower than Atomic transaction.
Note: Atomic transaction in BizTalk is not atomic in strict sense. It can include requests to the external processes, calls to the .NET classes, etc. Each of these processes could change something outside the orchestration and the transaction Rollback does not automatically roll back all these changes. It would be dangerous.
The Atomic transaction is short by definition. It cannot nest other transactions inside. The Atomic transaction is processed as a single unit of work. If Exception is fired inside the Atomic transaction, all we have to do is to roll back this transaction. And BizTalk makes this automatically. We cannot change this roll back process no matter what sort of Exception was fired.
The main difference between the Atomic and LongRunning transactions in BizTalk, how they behave in case of the internal Exception. Atomic transaction always automatically performs Rollback. We cannot avoid this Rollback and cannot do something else. LongRunning transaction could catch the Exception in the optional Exception block and process additional rollback operations in specific custom code. But the Exception block cannot prevent the automatic Rollback. The Rollback occurs after executing the Exception block. If a LongRunning transaction does not have the Exception blocks it processes an Exception the same way as an Atomic transaction.
The likelihood of the system crash is bigger in the durations of hours and days than in seconds. That's why data inside LongRunning transaction persisted to disk. That's why the orchestration data used in the Long- Running transaction must be serializable. That's why the LongRunning transaction theoretically slower than Atomic transaction.
Note: Atomic transaction in BizTalk is not atomic in strict sense. It can include requests to the external processes, calls to the .NET classes, etc. Each of these processes could change something outside the orchestration and the transaction Rollback does not automatically roll back all these changes. It would be dangerous.
The Atomic transaction is short by definition. It cannot nest other transactions inside. The Atomic transaction is processed as a single unit of work. If Exception is fired inside the Atomic transaction, all we have to do is to roll back this transaction. And BizTalk makes this automatically. We cannot change this roll back process no matter what sort of Exception was fired.
The main difference between the Atomic and LongRunning transactions in BizTalk, how they behave in case of the internal Exception. Atomic transaction always automatically performs Rollback. We cannot avoid this Rollback and cannot do something else. LongRunning transaction could catch the Exception in the optional Exception block and process additional rollback operations in specific custom code. But the Exception block cannot prevent the automatic Rollback. The Rollback occurs after executing the Exception block. If a LongRunning transaction does not have the Exception blocks it processes an Exception the same way as an Atomic transaction.
Return to Return to Discussion Forum