Difference between revisions of "Stardust/Knowledge Base/Transaction Management/Understanding Transaction Management in Stardust"

Revision as of 02:52, 13 August 2013

Introduction

There is often a requirement to define units of work in a business process. The analyst may want a set of operations to be executed atomically (all-or-nothing). It is important to understand the transaction management process in Stardust to be able to define such execution semantics. It is relevant for the execution of a process to specify where a transaction starts and where it is committed. Specification of where a transaction begins and where it is committed is referred to as transaction demarcation. Transaction demarcation in Stardust is done implicitly and is compliant with the mechanisms of the EJB standard:

Normally, each call to start or continue a process demarcates the boundaries of a transaction. A two-phase commit is performed against all involved data sources after this call returns. If the client submitting this call has already demarcated a transaction, the commit may even be postponed until that point.

This article explores various transaction management scenarios under resource local and distributed transactions contexts involving the Stardust Audit Trail and external database. All artifacts referenced in the article may be downloaded from here.

Scenario

We consider a scenario where a Stardust process is kicked off and the user is prompted for some basic Employee information (Emp Id, First Name and Last Name). This data is persisted in a subsequent activity to the external data store. We simulate a TX Rollback exception by generating a PK violation from the database if the Emp Id provided already exists in the database. A Non-TX exception is generated if the Emp Id provided exceeds the value 1000.We execute this process repeatedly for the following conditions:

• Stardust Exception Propagation mode - never, onRollback, always
  
• Transaction Management configuration - Resource Local, JTA
  
• Exception type: TX Rollback, Application Exception
  
• Service Exception - First service call, Second service call
  

We thus end up testing 24 scenarios.

Process Model

The following process model is considered for the following discussion.

As shown in the model above, we initially accept some user input pertaining to an employee.We can generate exceptions in the Emp Sevice App or Emp Service 2 App under the following conditions:

• TX Exception - If the Emp Id specified for the Employee matches an existing Emp Id in the Employee table, a duplicate PK exception is thrown by the database and results in a TX Rollback. For Emp Service 2 we generate the Emp Id using the following logic in the preceeding MTA activity - If Emp Id entered by user <10, subtract 1 and set that as the Emp Id for the  Emp Service 2 invocation, if the Emp Id entered  >=10, set the Emp Id to 1001. Emp Id values >1000 result in Application Exceptions as detailed below.
• Application Exception - If the Emp Id specified by the user >1000 it results in an Application Exception on the first sevice invocation. If the Emp Id specified >=10, it results in an Application Exception on the second service invocation.

The message transformation logic for the activity "MTA for Emp" is shown below: