|Oracle® Fusion Middleware Programming JTA for Oracle WebLogic Server
11g Release 1 (10.3.6)
Part Number E13731-05
|PDF · Mobi · ePub|
This chapter describes how WebLogic Server supports Logging Last Resource (LLR) transaction optimization through JDBC data sources. LLR is a performance enhancement option that enables one non-XA resource to participate in a global transaction with the same ACID guarantee as XA.
LLR is a refinement of the "Last Agent Optimization." It differs from Last Agent Optimization in that it is transactionally safe. The LLR resource uses a local transaction for its transaction work. The WebLogic Server transaction manager prepares all other resources in the transaction and then determines the commit decision for the global transaction based on the outcome of the LLR resource's local transaction.
In a global two-phase commit (2PC) transaction with an LLR participant, the WebLogic Server transaction manager follows these basic steps:
Calls prepare on all other (XA-compliant) transaction participants.
Inserts a commit record to a table on the LLR participant (rather than to the file-based transaction log).
Commits the LLR participant's local transaction (which includes both the transaction commit record insert and the application's SQL work).
Calls commit on all other transaction participants.
After the transaction completes successfully, lazily deletes the database transaction log entry as part of a future transaction.
The following sections provide more information about LLR transaction processing in WebLogic Server:
For more information about the advantages of LLR, see “Understanding the Logging Last Resource Transaction Option” in Configuring and Managing JDBC Data Sources for Oracle WebLogic Server.
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.
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:
Each WebLogic server instance maintains a database “LLR” table on the database to which a JDBC LLR data source pools database connections. These tables are used for storing transaction log records, and are automatically created. If multiple LLR data sources are deployed on the same WebLogic server instance and connect to the same database instance and database schema, they also share the same LLR table.
LLR table names are automatically generated unless administrators choose to configure them. The default table name is
WL_LLR_SERVERNAME. For some DBMS systems, the maximum length for a table name is 18 characters. You should consider maximum table name length when configuring your environment.
Note the following restrictions regarding LLR database tables:
The server does not boot if an LLR table is unreachable during boot. LLR transaction records must be available to correctly resolve in-doubt transactions during recovery, which runs automatically at server startup.
Multiple servers must not share the same LLR table. On server startup, WebLogic Server checks to ensure that the domain and server name of the JDBC data source match the domain and server name stored in the table when the table is created. If WebLogic Server detects that multiple servers are sharing the same LLR table, WebLogic Server instance shuts down one or more of the servers.
To change the table name used to store transaction log records for the resource, follow these steps:
In the Change Center in the upper-left corner of the Administration Console window, click Lock & Edit to start a configuration editing session.
On the Servers: Configuration: General page, click to Advanced to show the advanced configuration options. See
In JDBC LLR Table Name, enter the name of the table to use to store transaction records for the resource, then click Save. See “Servers: Configuration: General” in Oracle WebLogic Server Administration Console Help.
Repeat steps 2 and 3 for each server on which the LLR-enabled data source is deployed.
Click Activate Changes in the Change Center.
Note:You must restart all servers for the change to take effect.
For each committed 2PC LLR transaction, the transaction manager automatically inserts a transaction record into an LLR database table. Once LLR transactions complete, the transaction manager lazily deletes their transaction records. If an LLR table transaction log record delete fails, the server logs a warning message and retry the delete again later.
If you move a database that contains LLR transaction records, ensure that you move the LLR table contents to the new database so that transactions can be completed properly.
Note:Do not manually delete the LLR transaction records or the LLR table in a production system. Doing so can lead to silent heuristic transaction failures which are not logged.
In general, the WebLogic transaction manager processes transaction failures in the following way:
For two-phase commit errors that occur before the local transaction commit is attempted, the transaction manager immediately throws a transaction rolled back exception.
For two-phase commit errors that occur during the local transaction commit, the behavior depends on whether the transaction record is written to the database:
If the record is written, the transaction manager commits the transaction.
If the record is not written, the transaction manager rolls back the transaction.
If it is unknown whether the record is written, the transaction manager throws an ambiguous commit failure exception and attempts to complete the transaction every 5 seconds until the transaction abandon timeout. If the transaction is still incomplete, the transaction manager logs an abandoned transaction message.
If a transaction's coordinating server crashes before an LLR resource stores its transaction log record or before an LLR resource commits, the transaction rolls back. If the server crashes after the LLR resource is committed, the transactions eventually fully commit. During server boot, the transaction coordinator uses the LLR resource to read the transaction log record from the database and then use the recovered information to commit any unfinished work on any participating non-LLR XA resources.
If the JDBC connection in an LLR resource fails during a 2PC transaction record insert, the transaction manager rolls back the transaction.
If the JDBC connection in an LLR resource fails during the commit of the local transaction, the result depends on whether the transaction is a one-phase commit (1PC, where the LLR resource is the only participant) or 2PC:
For a 1PC transaction, the transaction are fully committed, fully rolled back, or block waiting for the resolution of the local transaction. The outcome of the transaction is fully ACID because it is eventually fully committed or fully rolled back.
For a 2PC transaction, the outcome is as described in Failure and Recovery Processing for LLR.
During server startup, the transaction manager for each WebLogic server must recover incomplete transactions coordinated by the server, including LLR transactions. To do so, each server attempts to read the transaction records from the LLR database tables for each LLR data source. If the server cannot access the LLR database tables or if the recovery fails, the server instance does not start and the transaction manager marks the server with a bad health state: HealthState.HEALTH_FAILED.
If a timeout occurs during recovery, it may be due to unresolved local transactions that have locked rows within the LLR log tables. Such local transactions must be resolved so that the transaction manager can determine the state of the global transaction whose record is stored in the locked row. Local database transactions can only be diagnosed and resolved using each database's specific tools (the commands differ from database to database).
Consider the following notes and limitations regarding failover with LLR:
A transaction log (TLog) is still required for LLR transactions:
TLog still stores transaction manager "checkpoint" records
TLog must still be reachable or copied on failover
LLR supports server migration and transaction recovery service migration. To use the transaction recovery service migration, ensure that each LLR resource be targeted to either the cluster or the set of candidate servers in the cluster. See Recovering Transactions For a Failed Clustered Server.
This section includes the following information:
Within a global transaction with an LLR participant, WebLogic Server automatically routes all connection operations to the transaction's coordinating server. This routing can be expensive. You may see better performance if you optimize your applications to run directly on the coordinating server if possible, and optimize your applications to use connection instances that are directly hosted on the coordinator.
For client applications that begin a transaction, the coordinator of transaction is the first WebLogic server the client calls under the transaction (any RMI, EJB, JDBC, or JMS call). In the JMS case, this is the server that hosts the client's JMS connection, which is not necessarily the same as the server that hosts the JMS destination.
For server side applications, the coordinator of the transaction is the local server if a local resource is invoked first (including JMS destinations and JDBC connections) unless a remote server is called first (any remotely hosted JDBC connection, EJB, RMI call, or JMS connection). This includes remote servers in other clusters or domains.
The LLR optimization provides a significant increase in performance for insert, update, and delete operations. However, for read operations with LLR, performance is somewhat slower than read operations with XA. For best performance, you may want to configure a non-LLR JDBC data source for read-only operations.
To improve performance in environments using Oracle RAC, you can specify a LLR table for each data source instead of for each server to better utilize the local node caches in Oracle RAC clusters.
Use the following system property to set the specification of a LLR table by data source when starting a WebLogic Server instance:
datasourcename is the name of a data source and
tablename is the name of the LLR table that maps to
For example, using the system property:
When the server starts:
INFO message is written to
LLR data source LLRDS1 using LLR table myllrtable1
All LLR entries for the server that use data source LLRDS1 are stored in the LLR table named
Define one table for each data source on each server on which the data source is targeted. The same table cannot be shared by different WLS instances. If LLRDS1 is targeted to two WebLogic Server instances S1 and S2, then create two tables: S1_LLRDS1 and S2_LLRDS1, and specify the proper system properties for each server.
For instance S1, use
For instance S2, use
Note:In the next WebLogic Server release, the
node-idwill automatically be captured in an extended LLR table allowing data to be partitioned to the respective WebLogic Server node without needing to manually allocate a table per data source.