JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server 3.1 Administration Guide
search filter icon
search icon

Document Information


1.  Overview of GlassFish Server Administration

Default Settings and Locations

Configuration Tasks

Administration Tools

Instructions for Administering GlassFish Server

Part I Runtime Administration

2.  General Administration

3.  Administering Domains

4.  Administering the Virtual Machine for the Java Platform

5.  Administering Thread Pools

6.  Administering Web Applications

7.  Administering the Logging Service

8.  Administering the Monitoring Service

9.  Writing and Running JavaScript Clients to Monitor GlassFish Server

10.  Administering Life Cycle Modules

11.  Extending and Updating GlassFish Server

Part II Resources and Services Administration

12.  Administering Database Connectivity

13.  Administering EIS Connectivity

14.  Administering Internet Connectivity

15.  Administering the Object Request Broker (ORB)

16.  Administering the JavaMail Service

17.  Administering the Java Message Service (JMS)

18.  Administering the Java Naming and Directory Interface (JNDI) Service

19.  Administering Transactions

About Transactions

Transaction Resource Managers

Transaction Scope

Configuring the Transaction Service

Managing the Transaction Service for Rollbacks

To Stop the Transaction Service

To Roll Back a Transaction

To Restart the Transaction Service

Determining Local Transaction Completion at Shutdown

Recovering Transactions

Automatic Transaction Recovery

To Manually Recover Transactions

Distributed Transaction Recovery

Recovery Workarounds and Limitations

General Recovery Limitations

Oracle Setup for Transaction Recovery

Oracle Thin Driver

Delegated Recovery After Server Crash Doesn't Work on MySQL

Call to XATeminator.recover() During ResourceAdapter.start() Hangs If Automatic Recovery Is Enabled

Transaction Logging

To Store Transaction Logs in a Database

Part III Appendixes

A.  Subcommands for the asadmin Utility


About Transactions

A transaction is a series of discreet actions in an application that must all complete successfully. By enclosing one or more actions in an indivisible unit of work, a transaction ensures data integrity and consistency. If all actions do not complete, the changes are rolled back.

For example, to transfer funds from a checking account to a savings account, the following steps typically occur:

  1. Check to see if the checking account has enough money to cover the transfer.

  2. Debit the amount from the checking account.

  3. Credit the amount to the savings account.

  4. Record the transfer to the checking account log.

  5. Record the transfer to the savings account log.

These steps together are considered a single transaction.

If all the steps complete successfully, the transaction is committed. If any step fails, all changes from the preceding steps are rolled back, and the checking account and savings account are returned to the states they were in before the transaction started. This type of event is called a rollback. A normal transaction ends in either a committed state or a rolled back state.

The following elements contribute to reliable transaction processing by implementing various APIs and functionalities:

The following topics are addressed here:

Transaction Resource Managers

There are three types of transaction resource managers:

Transaction Scope

A local transaction involves only one non-XA resource and requires that all participating application components execute within one process. Local transaction optimization is specific to the resource manager and is transparent to the Java EE application.

In the GlassFish Server, a JDBC resource is non-XA if it meets either of the following criteria:

A transaction remains local if the following conditions remain true:

Transactions that involve multiple resources or multiple participant processes are distributed or global transactions. A global transaction can involve one non-XA resource if last agent optimization is enabled. Otherwise, all resources must be XA. The use-last-agent-optimization property is set to true by default. For details about how to set this property, see Configuring the Transaction Service.

If only one XA resource is used in a transaction, one-phase commit occurs, otherwise the transaction is coordinated with a two-phase commit protocol.

A two-phase commit protocol between the transaction manager and all the resources enlisted for a transaction ensures that either all the resource managers commit the transaction or they all abort. When the application requests the commitment of a transaction, the transaction manager issues a PREPARE_TO_COMMIT request to all the resource managers involved. Each of these resources can in turn send a reply indicating whether it is ready for commit (PREPARED) or not (NO). Only when all the resource managers are ready for a commit does the transaction manager issue a commit request (COMMIT) to all the resource managers. Otherwise, the transaction manager issues a rollback request (ABORT) and the transaction is rolled back.