7-2 Programming JTA for Oracle WebLogic Server
7.1 About the LLR Optimization Transaction Optimization
In many cases a global transaction becomes a two-phase commit 2PC transaction because it involves a database operation using JDBC and another non-database
operation, such as a message queueing operation using JMS. In cases such as this where there is one database participant in a 2PC transaction, the Logging Last
Resource LLR Optimization transaction option can significantly improve transaction performance by eliminating some XA overhead for database processing and by
avoiding the use of JDBC XA drivers, which typically are less efficient than non-XA drivers. The LLR transaction option does not incur the same data risks as borne by the
Emulate Two-Phase Commit JDBC data source option and the NonXAResource resource adapter Connector option.
7.2 Logging Last Resource Processing Details
At server boot or data source deployment, LLR data sources load or create a table on the database from which the data source pools database connections. The table is
created in the schema determined by the user specified to create database connections. If the database table cannot be created or loaded, then server boot fails.
Within a global transaction, the first connection obtained from an LLR data source reserves an internal JDBC connection that is dedicated to the transaction. The internal
JDBC connection is reserved on the specific server that is also the transactions coordinator. All subsequent transaction operations on any connections obtained from
a same-named data source on any server are routed to this same single internal JDBC connection.
When an LLR transaction is committed, the WebLogic Server transaction manager handles the processing transparently. From an application perspective, the transaction
semantics remain the same, but from an internal perspective, the transaction is handled differently than standard XA transactions. When the application commits the
global transaction, the WebLogic Server transaction manager atomically commits the local transaction on the LLR connection before committing transaction work on any
other transaction participants. For a two-phase commit transaction, the transaction manager also writes a 2PC record on the database as part of the same local transaction.
After the local transaction completes successfully, the transaction manager calls commit on all other global transaction participants. After all other transaction
participants complete the commit phase, the related LLR 2PC transaction record is freed for deletion. The transaction manager lazily deletes the transaction record after a
short interval or with another local transaction.
If the application rolls back the global transaction or the transaction times out, the transaction manager rolls back the work in the local transaction and does not store a
2PC record in the database.
To enable the LLR transaction optimization, you create a JDBC data source with the Logging Last Resource transaction protocol, then use database connections from the
data source in your applications. WebLogic Server automatically creates the required table on the database.
See “Create LLR-enabled JDBC data sources” in the Oracle WebLogic Server Administration Console Help. Also see “Understanding the Logging Last Resource
Transaction Option” in Configuring and Managing JDBC Data Sources for Oracle WebLogic Server.
For a list of data source configuration and usage requirements and limitations, see the following topics in Configuring and Managing JDBC Data Sources for Oracle WebLogic
Server:
Logging Last Resource Transaction Optimization 7-3
■
Programming Considerations and Limitations for LLR Data Sources
■
Administrative Considerations and Limitations for LLR Data Sources
7.3 LLR Database Table Details