Transactions

Overview of transactions

The transaction management of HULFT Square complies with the Java Transaction API (JTA), which is a J2EE standard framework.

In HULFT Square, you can configure transactions for each of the following operations:

Script
Specified operation

Script transaction

If you want to set a transaction for each script, you can choose one among the following six types of transaction attributes:

NEVER
NOTSUPPORTED
SUPPORTS
REQUIRED
REQUIRESNEW
MANDATORY

Transaction attributes can be specified according to the following perspectives:

Transaction limitations of the call source

Specify which of the following limitations are necessary for the target scripts:

Limitation 1:

Scripts that support the transaction must be called (must be included in the transaction)

NEVER

Limitation 2:

Scripts must be called from target scripts that don't support the transaction (mustn't be included in the transaction)

NOTSUPPORTED, SUPPORTS, REQUIRED, REQUIRESNEW

Limitation 3:

Scripts can be called from target scripts that support any type of transaction

MANDATORY
Propagation of call source transactions

Specify whether the target script is executed as a transaction that is identical to the transaction of the call source after it's propagated.

Transaction attributes are as follows.

Transaction attributes	Perspective of settings	Description
NEVER (Limitation 1)	This attribute script can't be called from the following transaction attribute scripts: REQUIRED REQUIRESNEW MANDATORY	The call source transaction isn't propagated.	Transactions aren't supported. Also, the call source mustn't support transactions.
NOTSUPPORTED (Limitation 2)	No limitations. This attribute script can be called from any transaction attribute script.	The call source transaction isn't propagated.	Transactions aren't supported. Also, scripts don't take part in the transaction regardless of the transaction attribute of the call source.
SUPPORTS (Limitation 2)	No limitations. This attribute script can be called from any transaction attribute script.	If the call source supports a transaction, the target script propagates the transaction and is executed as an identical transaction. If the call source doesn't support a transaction, the transaction isn't propagated.	Transactions aren't supported by default. Also, depending on the transaction attribute of the call source, the transaction may or may not be supported. Note This attribute is the default transaction attribute value of the scripts.
REQUIRED (Limitation 2)	No limitations. This attribute script can be called from any transaction attribute script.	If the call source supports a transaction, the target script propagates the transaction and is executed as an identical transaction. If the call source doesn't support a transaction, the transaction is newly started.	Transactions are supported. Also, the behavior differs depending on the transaction attribute of the call source.
REQUIRESNEW (Limitation 2)	No limitations. This attribute script can be called from any transaction attribute script.	The transaction is newly started regardless of whether the call source supports the transaction.	Transactions are supported. Transactions are always newly started.
MANDATORY (Limitation 3)	This attribute script can't be called from the following transaction attribute scripts: NEVER NOTSUPPORTED SUPPORTS (when the call source doesn't support transactions)	The transaction of the call source is propagated and behaves as an identical transaction.	Transactions are supported. Also, the call source must always support transactions.

Transaction attributes

Perspective of settings

Description

1. Transaction limitations of the call source

2. Propagation of call source transactions

NEVER

(Limitation 1)

This attribute script can't be called from the following transaction attribute scripts:

REQUIRED
REQUIRESNEW
MANDATORY

The call source transaction isn't propagated.

Transactions aren't supported.

Also, the call source mustn't support transactions.

NOTSUPPORTED

(Limitation 2)

No limitations.

This attribute script can be called from any transaction attribute script.

The call source transaction isn't propagated.

Transactions aren't supported.

Also, scripts don't take part in the transaction regardless of the transaction attribute of the call source.

SUPPORTS

(Limitation 2)

No limitations.

This attribute script can be called from any transaction attribute script.

If the call source supports a transaction, the target script propagates the transaction and is executed as an identical transaction.
If the call source doesn't support a transaction, the transaction isn't propagated.

Transactions aren't supported by default.

Also, depending on the transaction attribute of the call source, the transaction may or may not be supported.

Note

This attribute is the default transaction attribute value of the scripts.

REQUIRED

(Limitation 2)

No limitations.

This attribute script can be called from any transaction attribute script.

If the call source supports a transaction, the target script propagates the transaction and is executed as an identical transaction.
If the call source doesn't support a transaction, the transaction is newly started.

Transactions are supported.

Also, the behavior differs depending on the transaction attribute of the call source.

REQUIRESNEW

(Limitation 2)

No limitations.

This attribute script can be called from any transaction attribute script.

The transaction is newly started regardless of whether the call source supports the transaction.

Transactions are supported.

Transactions are always newly started.

MANDATORY

(Limitation 3)

This attribute script can't be called from the following transaction attribute scripts:

NEVER
NOTSUPPORTED
SUPPORTS (when the call source doesn't support transactions)

The transaction of the call source is propagated and behaves as an identical transaction.

Transactions are supported.

Also, the call source must always support transactions.

List of transaction attribute relations of parent scripts and child scripts

The combinations of transaction attributes that can be set are as follows:

Transaction attributes		Available for setting
Child script	Parent script	Available for setting
NEVER	NEVER	valid
	NOTSUPPORTED	valid
	SUPPORTS	valid
	REQUIRED	invalid
	REQUIRESNEW	invalid
	MANDATORY	invalid
NOTSUPPORTED	NEVER	valid
	NOTSUPPORTED	valid
	SUPPORTS	valid
	REQUIRED	valid
	REQUIRESNEW	valid
	MANDATORY	valid
SUPPORTS	NEVER	valid
	NOTSUPPORTED	valid
	SUPPORTS	valid
	REQUIRED	valid
	REQUIRESNEW	valid
	MANDATORY	valid
REQUIRED	NEVER	valid
	NOTSUPPORTED	valid
	SUPPORTS	valid
	REQUIRED	valid
	REQUIRESNEW	valid
	MANDATORY	valid
REQUIRESNEW	NEVER	valid
	NOTSUPPORTED	valid
	SUPPORTS	valid
	REQUIRED	valid
	REQUIRESNEW	valid
	MANDATORY	valid
MANDATORY	NEVER	invalid
	NOTSUPPORTED	invalid
	SUPPORTS	valid Note When the call source script to which SUPPORTS is set supports transactions
	REQUIRED	valid
	REQUIRESNEW	valid
	MANDATORY	valid

valid	:	The attribute can be set.
invalid	:	The attribute can't be set.

How to set transaction attributes

Transaction attributes can be set in the Transaction tab of the Script properties dialog.

Transaction component

In HULFT Square, you can configure transactions by specified operations.

To configure the transactions for each specified operation, use the Transaction component.

Transaction components always start a new transaction. The behavior is identical to that of the transaction attribute REQUIRESNEW.

Connector transactions

Transactions for connectors that support transactions are executed for each component icon.

Component icons that meet the following conditions are executed in an identical transaction:

When component icons are placed in an identical script that supports a transaction
When component icons are placed in an identical Transaction component

Note

The connectors in the File category behave differently.

For details, refer to Transactions for the connectors in the File category.

XAResource and Non-XAResource

The connection resources of some connectors are either XAResource or Non-XAResource.

XAResource is a resource for global transactions with a two-phase commit function, while Non-XAResource is a resource without a two-phase commit function.

Global transaction (also called distributed transaction) is a transaction that spans multiple resources.

Differences between XAResource and Non-XAResource transactions

The differences between transactions that use XAResource and transactions that use Non-XAResource are as follows:

Transaction flow when using Non-XAResource
1. Start of transaction
2. Commit or rollback
Transaction flow when using XAResource
1. Start of transaction
2. Prepare
3. Commit or rollback

When XAResource is used, a processing called prepare is executed prior to the completion of the transaction (before commit or rollback). This type of processing is called two-phase commit. In transactions that span multiple resources, this prepare processing fulfills an important role.

Transaction example

To create a global transaction that spans multiple resources, it's recommended that you use XAResource which supports the two-phase commit.

The differences in behavior between XAResource and Non-XAResource are explained through the following examples:

The above script is processed by an identical transaction.

Also, in this example, the "writing 2" operation of the script is exceptionally long, and a transaction timeout occurs during the commit of "writing 1."

When Non-XAResource is used
1. A transaction is started
2. "writing 1" is successful
3. "writing 2" is successful
  
  > "writing 2" is exceptionally long
4. Because the full transaction is successful, "writing 1" and "writing 2" are committed
  1. "writing 1" is committed
    
    The commit fails due to a transaction timeout
  2. "writing 2" is committed
    
    The commit is successful
Figure 3.1 When Non-XAResource is used

When Non-XAResource is used, it's possible that the atomicity of the transaction (either completely successful or completely failed) may break down.

When XAResource is used
1. A transaction is started
2. "writing 1" is successful
3. "writing 2" is successful
  
  > "writing 2" is exceptionally long
4. Because the full transaction is successful, "writing 1" and "writing 2" are prepared
  1. "writing 1" is prepared
    
    A transaction timeout is detected, and prepare fails
5. Because prepare processing failed, the transaction is rolled back
  1. "writing 1" is rolled back
  2. "writing 2" is rolled back
Figure 3.2 When XAResource is used

When XAResource is used, the failure to commit "writing 1" is detected during the prepare processing and the entire transaction is rolled back even if the prepare processing for "writing 2" is successful. Therefore, the transaction atomicity that may break down in Non-XAResource can be retained.

Transactions for the connectors in the File category

Transactions for the write operation of the connectors in the File category are implemented according to the following flow:

A transaction is started
Data is written to a temporary file
The specified write destination is checked if it is updated since the start of the transaction

> When the write destination is updated, an XAException occurs and the transaction fails
The data is copied from the temporary file to the specified write destination, and the temporary file is deleted (when committed)

> The write destination file specified by the connector is updated
The temporary file is deleted (when rolled back)

> The write destination file specified by the connector isn't updated

Write operations of the connectors in the File category don't execute the transaction by default regardless of the script transaction attributes.

To execute the transaction, select Properties from the right-click menu of the component icon and select Execute transaction processing in the Transaction tab.

When the transaction is enabled and the script takes part in the transaction, the component takes part in the transaction. If the script doesn't take part in transactions, transaction is performed by the component.

Note

When the write operation of the connectors in the File category takes part in a transaction, a rollback isn't performed if commit fails because of a network disruption or if the write process fails because of unexpected errors.