Chapter 12 Transactions
By enclosing one
or more steps in an indivisible unit of work, a transaction ensures data integrity
and consistency. This chapter contains the following sections:
About Transactions
What is a Transaction?
A transaction is a series of discreet actions in an application that
must all complete successfully or else all the changes in each action are
backed out. For example, to transfer funds from a checking account to a savings
account is a transaction with the following steps:
-
Check to see if the checking account has enough money to cover
the transfer.
-
If there’s enough money in the checking account debit
the amount from the checking account.
-
Credit the money to the savings account.
-
Record the transfer to the checking account log.
-
Record the transfer to the savings account log.
If any of these steps fails, all changes from the preceding steps must
be backed out, and the checking account and savings account must be in the
same state as they were before the transaction started. This event is called
a rollback.
If all the steps complete successfully, the transaction is in a committed state. Transactions end in either a commit or a rollback.
See Also:
Transactions in Java EE Technology
Transaction processing in Java EE technology involves the following
five participants:
-
Transaction
Manager
-
Application Server
-
Resource
Manager(s)
-
Resource
Adapter(s)
-
User Application.
Each of these entities contribute to reliable transaction processing
by implementing the different APIs and functionalities, discussed below:
-
The Transaction Manager provides the services and management
functions required to support transaction demarcation, transactional resource
management, synchronization, and transaction context propagation.
-
The Application Server provides the infrastructure required to
support the application runtime environment that includes transaction state
management.
-
The Resource Manager (through a resource adapter) provides
the application access to resources. The resource manager participates in distributed
transactions by implementing a transaction resource interface used by the
transaction manager to communicate transaction association, transaction
completion and recovery work. An example of such a resource manager is a relational
database server.
-
A Resource Adapter is a system level software library that
is used by the application server or client to connect to a Resource Manager.
A Resource Adapter is typically specific to a Resource Manager. It is available
as a library and is used within the address space of the client using it.
An example of such a resource adapter is a JDBC driver.
-
A Transactional User Application developed to operate in an
application server environment looks up transactional data sources and, optionally,
the transaction manager, using JNDI. The application may use declarative transaction
attribute settings for enterprise beans or explicit programmatic transaction
demarcation.
See Also:
Workarounds for Specific Databases
The Application Server provides workarounds for some known issues with the
recovery implementations of the following JDBC drivers. These workarounds
are used unless explicitly disabled.
-
Oracle thin driver - The XAResource.recover method repeatedly returns the same set of in-doubt
Xids regardless of the input flag. According to the XA specifications, the
Transaction Manager initially calls this method with TMSTARTSCAN and then
with TMNOFLAGS repeatedly until no Xids are returned. The XAResource.commit method also has some issues.
To disable the Application Server workaround,
set the oracle-xa-recovery-workaround property value
to false. For details about how to set a property, see To configure how the Application Server recovers from transactions.
Note –
These workarounds do not imply support for any particular JDBC
driver.
Admin Console Tasks for Transactions
The Application Server handles transactions based on the settings in the Admin Console.
Configuring Transactions
This section explains how to configure transaction settings:
For additional information about transactions, see these sections:
To configure how the Application Server recovers from transactions
Transactions might be incomplete either because the server crashed or
a resource manager crashed. It is essential to complete these stranded transactions
and recover from the failures. Application Server is designed to recover from these
failures and complete the transactions upon server startup.
While performing the recovery, if some of the resources are unreachable
the server restart may be delayed as it tries to recover the transactions.
When the transaction spans across servers, the server that started the
transaction can contact the other servers to get the outcome of the transactions.
If the other servers are unreachable, the transaction uses the Heuristic Decision
field to determine the outcome.
-
In the tree component select the Configurations node.
-
Select the
instance to configure:
-
To configure a particular instance, select the instance’s
config node. For example, the default instance, server,
select the server-config node.
-
To configure the default settings for all instances, select the default-config node.
-
Select the Transaction Service node.
-
To enable the recovery of incomplete transactions, check the Recover
in the On Restart field.
-
Set the amount of time, in seconds, the Application Server tries to
connect to the unreachable server in the Retry Timeout field. The default
value is 10 minutes (600 seconds).
-
Set the policy for unreachable servers in a transaction in the
Heuristic Decision field.
Unless there is a good reason to set
this field to Commit, leave Heuristic Decision set to Rollback. Committing
indeterminate transactions can compromise the data integrity of your application.
-
Set any needed properties.
Click the Add Properties
button, type values in the Name and Value fields, and check the box to the
left of the Name to activate the property.
-
Click Save.
-
Restart the Application Server.
To set a transaction timeout value
By default, the server does not timeout a transaction. That is, the
server waits indefinitely for a transaction to complete. If you set a timeout
value for transactions, if a transaction isn’t completed within the
configured time, the Application Server rolls back the transaction.
-
In the tree component, select the Configurations node.
-
Select the
instance to configure:
-
To configure a particular instance, select the instance’s
config node. For example, the default instance, server,
select the server-config node.
-
To configure the default settings for all instances, select the default-config node.
-
Select the Transaction Service node.
-
Enter the number of seconds before the transaction times out,
in the Transaction Timeout field.
The default value of Transaction
Timeout is 0 seconds. This disables transaction timeouts.
-
Click Save.
-
Restart the Application Server.
To set the location of the transaction logs
The transaction log records the information about each transaction in
order to maintain the data integrity of the resources involved and to recover
from failures. Transaction logs are kept in the tx subdirectory
of the directory specified by the Transaction Log Location field. These logs
are not human readable.
-
In the tree component, select the Configurations node.
-
Select the
instance to configure:
-
To configure a particular instance, select the instance’s
config node. For example, the default instance, server,
select the server-config node.
-
To configure the default settings for all instances, select the default-config node.
-
Select the Transaction Service node.
-
Enter the location of the transaction logs in the Transaction
Log Location field.
A tx subdirectory is created
and transaction logs are kept under that directory.
The default value is ${com.sun.aas.instanceRoot}/logs.
The ${com.sun.aas.instanceRoot} variable is the name of
the instance, and is set when you start an Application Server instance. To see
the value of ${com.sun.aas.instanceRoot}, click Actual
Values.
-
Click Save.
-
Restart the Application Server.
To set the keypoint interval
Keypoint
operations compress the transaction log file. The keypoint interval is the number of transactions
between keypoint operations on the log. Keypoint operations can reduce the
size of the transaction log files. A larger number of keypoint intervals (for
example, 2048) results in larger transaction log files, but fewer keypoint
operations, and potentially better performance. A smaller keypoint interval
(for example, 256) results in smaller log files but slightly reduced performance
due to the greater frequency of keypoint operations.
-
In the tree component select the Configurations node.
-
Select the
instance to configure:
-
To configure a particular instance, select the instance’s
config node. For example, the default instance, server,
select the server-config node.
-
To configure the default settings for all instances, select the default-config node.
-
Select the Transaction Service node.
-
Enter the number of transactions between keypoint operations in
the Keypoint Interval field.
The default value
is 2048.
-
Click Save.
-
Restart the Application Server.