Oracle GlassFish Server 3.0.1 Application Development Guide

Transactions

The following features pertain to transactions:

Using Non-Transactional Connections

You can specify a non-transactional database connection in any of these ways:

Typically, a connection is enlisted in the context of the transaction in which a getConnection call is invoked. However, a non-transactional connection is not enlisted in a transaction context even if a transaction is in progress.

The main advantage of using non-transactional connections is that the overhead incurred in enlisting and delisting connections in transaction contexts is avoided. However, use such connections carefully. For example, if a non-transactional connection is used to query the database while a transaction is in progress that modifies the database, the query retrieves the unmodified data in the database. This is because the in-progress transaction hasn’t committed. For another example, if a non-transactional connection modifies the database and a transaction that is running simultaneously rolls back, the changes made by the non-transactional connection are not rolled back.

Here is a typical use case for a non-transactional connection: a component that is updating a database in a transaction context spanning over several iterations of a loop can refresh cached data by using a non-transactional connection to read data before the transaction commits.

Using JDBC Transaction Isolation Levels

For general information about transactions, see Chapter 15, Using the Transaction Service and Chapter 21, Administering Transactions, in Oracle GlassFish Server 3.0.1 Administration Guide. For information about last agent optimization, which can improve performance, see Transaction Scope.

Not all database vendors support all transaction isolation levels available in the JDBC API. The GlassFish Server permits specifying any isolation level your database supports. The following table defines transaction isolation levels.

Table 14–1 Transaction Isolation Levels

Transaction Isolation Level 

Description 

read-uncommitted

Dirty reads, non-repeatable reads, and phantom reads can occur. 

read-committed

Dirty reads are prevented; non-repeatable reads and phantom reads can occur. 

repeatable-read

Dirty reads and non-repeatable reads are prevented; phantom reads can occur. 

serializable

Dirty reads, non-repeatable reads and phantom reads are prevented. 

You can specify the transaction isolation level in the following ways:

Note that you cannot call setTransactionIsolation during a transaction.

You can set the default transaction isolation level for a JDBC connection pool. For details, see Creating a JDBC Connection Pool.

To verify that a level is supported by your database management system, test your database programmatically using the supportsTransactionIsolationLevel method in java.sql.DatabaseMetaData, as shown in the following example:

InitialContext ctx = new InitialContext();
DataSource ds = (DataSource)
ctx.lookup("jdbc/MyBase");
Connection con = ds.getConnection();
DatabaseMetaData dbmd = con.getMetaData();
if (dbmd.supportsTransactionIsolationLevel(TRANSACTION_SERIALIZABLE)
{ Connection.setTransactionIsolation(TRANSACTION_SERIALIZABLE); }

For more information about these isolation levels and what they mean, see the JDBC API specification.


Note –

Applications that change the isolation level on a pooled connection programmatically risk polluting the pool, which can lead to errors.