7-4 Programming JTA for Oracle WebLogic Server
7.4 Failure and Recovery Processing for LLR
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.
7.4.1 Coordinating Server Crash
If a transactions 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.
7.4.2 JDBC Connection Failure
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 Section 7.4, Failure and
Recovery Processing for LLR .
7.4.3 LLR Transaction Recover During Server Startup
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
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.
Logging Last Resource Transaction Optimization 7-5
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 databases specific tools the commands differ from database to database.
7.4.4 Failover Considerations for LLR
Kategori