Exit Print View

Sun GlassFish Enterprise Server v3 Application Development Guide

  This Document Entire Library
Print View

Document Information

Preface

Part I Development Tasks and Tools

1.  Setting Up a Development Environment

2.  Class Loaders

3.  Using Ant with Enterprise Server

4.  Debugging Applications

Part II Developing Applications and Application Components

5.  Securing Applications

6.  Developing Web Services

7.  Using the Java Persistence API

8.  Developing Web Applications

9.  Using Enterprise JavaBeans Technology

10.  Using Container-Managed Persistence

11.  Developing Java Clients

12.  Developing Connectors

13.  Developing Lifecycle Listeners

Part III Using Services and APIs

14.  Using the JDBC API for Database Access

15.  Using the Transaction Service

Transaction Resource Managers

Transaction Scope

Configuring the Transaction Service

The Transaction Manager, the Transaction Synchronization Registry, and UserTransaction

Transaction Logging

Storing Transaction Logs in a Database

Recovery Workarounds and Limitations

Oracle Thin Driver

Manual Transaction Recovery Limitation

16.  Using the Java Naming and Directory Interface

17.  Using the Java Message Service

18.  Using the JavaMail API

Index

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 Enterprise 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 resourced 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.