In this article, we will see how to enable logging using log4net and see the advantage of using Parallel Invoke over delegate. Here is the simple console and I added the reference of Log4net; using log4net api I added tracing statements as shown.
I have used delegate to invoke LogM1 and LogM2 methods that would in turn invoke M1 and M2 methods using Parallel For Loop, M1 and M2 writes the trace details as shown below.
Lets run and verify the logs. Though, we use delegate to invoke the methods, we clearly see, M2 is invoked or started; post completion of M1 method. As Parallel FOR loop invokes M1 and M2, logging are captured in a random manner.
Instead of delegate, lets now refactor the code to use Parallel Invoke method as shown below.
Lets run and verify the behaviour. Both M1 and M2 are parallel invoked and all the logs are captured in a random manner; execution time is also faster comparatively to earlier way using delegate.
In this article, I should explain how to handle exception in Long Running Process and Atomic Process. BizTalk Server supports two distinct types of transactions: Atomic and Long-running. You can set an orchestration with the transaction type at the orchestration level or, if you need a finer level of granularity for configuring transaction behavior, you can define a scope to wrap a unit of work within a transaction boundary. Atomic transactions: This enables a transaction to automatically role back to a previous state in case the transaction does not successfully complete. Supports ACID, in BizTalk, you can design orchestrations to support ACID transactions by configuring the scope (or the entire orchestration itself) as atomic. Any variables, messages, etc., within an atomic scope are isolated within the transaction and changes to their state are not visible until after the transaction commits. Atomic transactions are married with the appropriate isolation level. Choices include serializable (object-level locking), read committed (only committed data is readable) and repeatable read (row-level locking occurs to prevent “dirty” reads). Long-running Transactions: Can span days, weeks, and longer time durations, contain nested transactions, and use custom exception handling to recover from error scenarios. Supports Consistency and Durability Nesting of Transactions:
Long Running Transaction (LRT) supports nesting of transactions (Atomic or LRT), whereas Atomic doesn’t support nesting.
Atomic scope support compensate block only but LRT supports both exception and compensate blocks.
Here is simple LRT process which receives a message and does a parallel process on a copy of received message inside a LRT scopes as shown. Both Left and Right scope have compensation block and these are wrapped inside as Main LRT scope that logs the error and invokes compensate block for Left and Right. Log expression writes an entry to event logs.
I have a simple helper method to generate random errors, which is invoked in expression shape on Left and Right scopes; here is the snap shot of helper class. Deploy and test the solution.
Event Logs of the process,
Conclusion In this article, I covered exception handling for Atomic and LRT transaction with the help of compensation block. Now you can apply this solution to your own business scenario. The video demonstration is available on the Youtube, here is the embedded video.
I have used delegate to invoke LogM1 and LogM2 methods that would in turn invoke M1 and M2 methods using Parallel For Loop, M1 and M2 writes the trace details as shown below.
Lets run and verify the logs. Though, we use delegate to invoke the methods, we clearly see, M2 is invoked or started; post completion of M1 method. As Parallel FOR loop invokes M1 and M2, logging are captured in a random manner.
Instead of delegate, lets now refactor the code to use Parallel Invoke method as shown below.
Lets run and verify the behaviour. Both M1 and M2 are parallel invoked and all the logs are captured in a random manner; execution time is also faster comparatively to earlier way using delegate.
