The Logging Last Resource (LLR) transaction optimization through JDBC data sources safely reduces the overhead of two-phase transactions involving database inserts, updates, and deletes. Two phase transactions occur when two different resources participate in the same global transaction (global transactions are often referred to as “XA” or “JTA” transactions). Consider the following:
Typical two-phase transactions in JMS applications usually involve both a JMS server and a database server. The LLR option can as much as double performance compared to XA.
The safety of the JDBC LLR option contrasts with well known but less-safe XA optimizations such as “last-agent”, “last-participant”, and “emulate-two-phase-commit” that are available from other vendors as well as WebLogic.
JDBC LLR works by storing two-phase transaction records in a database table rather than in the transaction manager log (the TLOG).
JDBC LLR generally improves performance of two-phase transactions that involve SQL updates, deletes, or inserts.
LLR generally reduces the performance of two-phase transactions where all SQL operations are read-only (just selects).
JDBC LLR pools provide no performance benefit to WebLogic JDBC stores. WebLogic JDBC stores are fully transactional but do not use JTA (XA) transactions on their internal JDBC connections.
Consider using LLR instead of the less safe “last-agent” optimization for connectors, and the less safe “emulate-two-phase-commit” option for JDBC connection pools (formerly known as the “enable two-phase commit” option for pools that use non-XA drivers).
On Oracle databases, heavily used LLR tables may become fragmented over time, which can lead to unused extents. This is likely due to the highly transient nature of the LLR table's data. To help avoid the issue, set PCT_FREE to 5 and PCT_USED to 95 on the LLR table. Also periodically defragment using the ALTER TABLESPACE [tablespace-name] COALESCE command.
