Which WebLogic optimization allows one nonXA resource to participate in a distributed transaction?

Question

Options

• Aenabling Pinned to Thread
• Benabling Logging Last Resource
• Cincreasing the Statement cache size
• Dsetting the statement cache type to LRU
• Esetting the initial and maximum capacity to the same number

• A
  3% (1)
• B
  71% (22)
• C
  3% (1)
• D
  16% (5)
• E
  6% (2)

Explanation

Logging Last Resource (LLR) is a WebLogic optimization that allows a single non-XA (non-distributed-transaction-capable) resource - typically a JDBC data source - to participate in a distributed (XA) transaction by treating it as the "last" resource to commit, recording the commit decision in the transaction log first. If the system crashes after the log write but before the non-XA commit, recovery can replay the commit, preserving data integrity without requiring full XA support from the resource.

Why the distractors are wrong:

• A (Pinned to Thread): This is a connection pool setting that keeps a connection pinned to a thread for performance, but it has nothing to do with enabling non-XA participation in distributed transactions.
• C (Statement cache size): This controls how many prepared SQL statements are cached per connection - purely a performance tuning knob, unrelated to transaction coordination.
• D (Statement cache type LRU): This sets the eviction strategy for the statement cache (Least Recently Used vs. Fixed), again purely a caching concern with no bearing on transaction participation.
• E (Equal initial/maximum capacity): Setting these equal pre-allocates the full connection pool at startup to avoid runtime growth overhead - a performance tuning choice, not a transaction protocol feature.

Memory tip: Think of Logging Last Resource as the "last one to commit, first to log" trick - it logs the intent, then commits the last (non-XA) resource, which is exactly how it sounds.

No community discussion yet for this question.