Part I Development Tasks and Tools
1. Setting Up a Development Environment
Part II Developing Applications and Application Components
6. Using the Java Persistence API
7. Developing Web Applications
8. Using Enterprise JavaBeans Technology
9. Using Container-Managed Persistence
12. Developing Lifecycle Listeners
13. Developing OSGi-enabled Java EE Applications
Part III Using Services and APIs
14. Using the JDBC API for Database Access
15. Using the Transaction Service
Handling Transactions with Enterprise Beans
Bean-Level Container-Managed Transaction Timeouts
Handling Transactions with the Java Message Service
Transactions and Non-Persistent Messages
Using the ConfigurableTransactionSupport Interface
The Transaction Manager, the Transaction Synchronization Registry, and UserTransaction
16. Using the Java Naming and Directory Interface
The following topics are addressed here:
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 15-1 Transaction Isolation Levels
|
By default, the transaction isolation level is undefined (empty), and the JDBC driver's default isolation level is used. You can specify the transaction isolation level in the following ways:
Select the value from the Transaction Isolation drop-down list on the New JDBC Connection Pool or Edit Connection Pool page in the Administration Console. For more information, click the Help button in the Administration Console.
Specify the --isolationlevel option in the asadmin create-jdbc-connection-pool command. For more information, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.
Specify the transaction-isolation-level option in the asadmin set command. For example:
asadmin set domain1.resources.jdbc-connection-pool.DerbyPool.transaction-isolation-level=serializable
For more information, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.
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 To Create a JDBC Connection Pool in Oracle GlassFish Server 3.1 Administration Guide.
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.
Setting or resetting the transaction isolation level for every getConnection call can degrade performance. So by default the isolation level is not guaranteed.
Applications that change the transaction isolation level on a pooled connection programmatically risk polluting the JDBC connection pool, which can lead to errors. If an application changes the isolation level, enabling the is-isolation-level-guaranteed setting in the pool can minimize such errors.
You can guarantee the transaction isolation level in the following ways:
Check the Isolation Level Guaranteed box on the New JDBC Connection Pool or Edit Connection Pool page in the Administration Console. For more information, click the Help button in the Administration Console.
Specify the --isisolationguaranteed option in the asadmin create-jdbc-connection-pool command. For more information, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.
Specify the is-isolation-level-guaranteed option in the asadmin set command. For example:
asadmin set domain1.resources.jdbc-connection-pool.DerbyPool.is-isolation-level-guaranteed=true
For more information, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.
You can specify a non-transactional database connection in any of these ways:
Check the Non-Transactional Connections box on the New JDBC Connection Pool or Edit Connection Pool page in the Administration Console. The default is unchecked. For more information, click the Help button in the Administration Console.
Specify the ----nontransactionalconnections option in the asadmin create-jdbc-connection-pool command. For more information, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.
Specify the non-transactional-connections option in the asadmin set command. For example:
asadmin set domain1.resources.jdbc-connection-pool.DerbyPool.non-transactional-connections=true
For more information, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.
Use the DataSource implementation in the GlassFish Server, which provides a getNonTxConnection method. This method retrieves a JDBC connection that is not in the scope of any transaction. There are two variants.
public java.sql.Connection getNonTxConnection() throws java.sql.SQLException
public java.sql.Connection getNonTxConnection(String user, String password) throws java.sql.SQLException
Create a resource with the JNDI name ending in __nontx. This forces all connections looked up using this resource to be non transactional.
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.