Transaction

What is transaction

DataSpider Servista's transaction management complies with JTA(Java Transaction API) defined in J2EE specification.
In DataSpider, transaction boundaries can be set script wide or at the beginning and the end of a specified process.

Script wide transaction

When declaring script wide transaction boundary, there are 6 transaction attributes to Select from and
there are two facets of transaction attributes when determining which one to apply.

Transaction propagation behavior is limited by the caller of the script.
A script enclosed within another can fit into one of the following.
- A script needs to be invoked within from its enclosing script which is declared to be transactional. In other words, the script must to run within the existing transaction which is already under way.
- A script needs to be invoked within from its enclosing script which is non transactional, therefore the script enclosed cannot be declared transactional.
- A script can be invoked within from its enclosing script regardless of whether it is declared to be transactional or not.
Propagation behavior of a transaction
Configure whether the script must run within the existing transaction of its enclosing script.

Transaction attributes	Limitations	Propagation behavior	Description
NEVER	Indicates that the script cannot be invoked by its enclosing scripts declared to be transactional with the following transaction attributes. REQUIRED REQUIRES_NEW MANDATORY	The existing transaction of its enclosing script is not propagated.	Indicates that the script should not run within a transactional context. Its enclosing script should not support transaction.
NOT_SUPPORTED	No limitations Indicates that the script can run within its enclosing script with any transaction attributes.	The existing transaction of its enclosing script is not propagated.	Transaction is not supported. Does not run within an existing transaction regardless of the transaction attribute of the enclosing script.
SUPPORTS	No limitations Indicates that the script can run within its enclosing script with any transaction attributes.	If an existing transaction is in progress, the script will run within that transaction. If no transaction is supported by the enclosing script, the script does not run within a transactional context.	Depending on the transaction attribute of the enclosing script, the script may or may not support transaction. The default does not support transaction. This is the default transaction attribute of a script
REQUIRED	No limitations Indicates that the script can run within its enclosing script with any transaction attributes.	If an existing transaction is in progress, the script will run within that transaction. If no transaction is supported by the enclosing script, a new transaction will be started.	Supports transaction. The script may run within the existing transaction or start a new transaction depending on the transaction attribute of its enclosing script.
REQUIRES_NEW	No limitations Indicates that the script can run within its enclosing script with any transaction attributes.	Always starts a new transaction, regardless of whether there is an existing transaction of its enclosing script or not.	Supports transaction Always starts a new transaction
MANDATORY	Indicates that the script cannot be invoked by its enclosing scripts declared to be transactional with the following transaction attributes. NEVER NOT_SUPPORTED SUPPORTS(The enclosing script does not support a transaction)	SUPPORTS(The enclosing script does not support a transaction)	Transaction is supported. The enclosing script must support transaction.

A table representing the combination of transaction attributes of a parent and a child script.

Transaction attribute		valid or invalid
Child script	Parent script	valid or invalid
NEVER	NEVER	valid
	NOT_SUPPORTED	valid
	SUPPORTS	valid
	REQUIRED	invalid
	REQUIRES_NEW	invalid
	MANDATORY	invalid
NOT_SUPPORTED	NEVER	valid
	NOT_SUPPORTED	valid
	SUPPORTS	valid
	REQUIRED	valid
	REQUIRES_NEW	valid
	MANDATORY	valid
SUPPORTS	NEVER	valid
	NOT_SUPPORTED	valid
	SUPPORTS	valid
	REQUIRED	valid
	REQUIRES_NEW	valid
	MANDATORY	valid
REQUIRED	NEVER	valid
	NOT_SUPPORTED	valid
	SUPPORTS	valid
	REQUIRED	valid
	REQUIRES_NEW	valid
	MANDATORY	valid
REQUIRES_NEW	NEVER	valid
	NOT_SUPPORTED	valid
	SUPPORTS	valid
	REQUIRED	valid
	REQUIRES_NEW	valid
	MANDATORY	valid
MANDATORY	NEVER	invalid
	NOT_SUPPORTED	invalid
	SUPPORTS	valid The parent script supports transaction and has the SUPPORTS transaction attribute.
	REQUIRED	valid
	REQUIRES_NEW	valid
	MANDATORY	valid

Transaction Component

In DataSpider, transaction boundaries can also be set at the beginning and the end of a specified process.
To define a transaction for a specified process, a transaction component is used.

Transaction component always start a new transaction and is equivalent to REQUIRES_NEW transaction attribute.

Transaction of an adapter

The boundary of the transaction supported by an adapter is usually set at the beginning and the end of its operation.
However, if the adapter is placed within a script that is declared to be transactional or if it is placed within a transaction component, the operation is executed within the transaction already under way.

Adapters categorized in file operation uses different type of transaction.

Please refer to File transaction for details.

To find out whether an adapter supports transaction or not, please refer to the Transaction section discussed in the document for each adapter.

XAResource and Non-XAResource

Some global resources are both XAResource and Non-XAResource.
XAResource is a transactional resource which can participate in global transaction and is capable of two-phase commit, whereas Non-XAResource is a resource which does not support two-phase commit.
Global transaction is same as the distributed transaction which is a an operation bundle, in which 2 or more transactional resources are involved.

Difference between XAResource and Non-XAResource

The steps involved in a transactional process used with each of those resources are as follows:

The steps involved in a transaction when Non-XAResource is used.
1. Start transaction
2. Commit/Rollback
The steps involved in a transaction when XAResource is used.
1. Start transaction
2. Prepare
3. Commit/Rollback

When a XAResource is used, there is a phase called "Prepare" during which the coordinator of the transaction asks participants to prepare to commit or to roll back the changes that were made.This process is called a two-phase commit. In a transaction that is coordinated across multiple resources, this "Prepare" phase plays an important roll.

Transaction

The behavioral differences between transactions for a XAResource and for a Non-XAResource are illustrated in the following diagrams.

Each of the write operation placed in the above script to which a transactional boundary is set becomes spontaneously transactional.
It is assumed here that the operation of 'writing 2' takes very long, resulting the timeout of the operation of 'writing 1' .

When resources are Non-XAResources
1. Transaction for the script starts.
2. The operation of 'writing 1' succeeds.
3. The operation of 'writing 2' succeeds
  ,but it took very long to complete.
4. Both write operations have been succeeded and the database transactions for both 'writing 1' and 'writing 2' are committed.
  1. committing fails for the database transaction started for 'writing 1'
    due to its transaction timeout.
  2. committing succeeds for the database transaction started for 'writing 2'.

When resources are Non-XAResources

The atomicity of the transaction(either all occur, or nothing occurs) set to the boundary of the above script is not guaranteed, if the resources are Non-XAResources.

When resources are XAResources
1. Transaction for the script starts.
2. The operation of 'writing 1' succeeds.
3. The operation of 'writing 2' succeeds,
  ,but it took very long to complete.
4. Both write operations have been succeeded and the database transactions for both 'writing 1' and 'writing 2' are prepared.
  1. Timeout occurs and the preparing for the operation of 'writing 1' fails.
    As the preparing has failed, each of the database transaction rolls back.
5. As the preparing has failed, each of the database transaction rolls back.
  1. The operation of 'writing 1' is rolled back.
  2. The operation of 'writing 2' is rolled back.

When resources are XAResources

The atomicity is guaranteed across the transaction set to the boundary of the above script if the participants of the transaction are XAResources; The transaction is rolled back, if any of the preparing for those resources fails.
It is thusly recommended to use XAResources which support 2 phase commit when creating a process that requires transaction coordination across multiple resources.

Transactions for the adapters categorized in File adapters

Transactions for write operations of the adapters in categorized in File adapters has the following behavioral characteristics.

Transaction for the script starts.
Write operation is performed to a temporary file.
Checks if the output destination file has been updated or not since the start of the transaction.
If the file has been modified, XAException will be thrown and the transaction fails.
If not, then the output which has been made to the temporary file is copied to the file. The temporary file is deleted at the transaction commit.
The destination is updated.
If the transaction fails, temporary file is deleted at the transaction roll back and
the destination is never updated.

The write operations of the adapters categorized in File adapters does not start transaction by default.
To enable adapter's transaction capability, enable [Execute transaction processing] check box found in the [Transaction] properties.
If the file adapter's transaction capability is enabled and the adapter is placed in a script which is transactional, the write operation of the adapter is performed within the same transaction.

However, if there is no transaction declared for the script, a transaction is started for each of the file adapter that has its transaction capability enabled.