Uploaded image for project: 'JBoss Enterprise Application Platform 4 and 5'
  1. JBoss Enterprise Application Platform 4 and 5
  2. JBPAPP-6345

Last Resource Commit Optimization (LRCO) in JBossTS JTA/JTS

    Details

    • Type: Feature Request
    • Status: Closed (View Workflow)
    • Priority: Optional
    • Resolution: Deferred
    • Affects Version/s: None
    • Fix Version/s: TBD
    • Component/s: Transaction Manager
    • Labels:
      None
    • Docs QE Status:
      NEW

      Description

      There is a window of opportunity where a system could crash between the commit of a Last Resource and the log of an XID, which would result in inconsistent state of transactional resources. If a crash occurred as shown below, the last resource would remain committed, while the XA capable resources would be rolled back on recovery.

      Steps:
      1. Begin transaction
      2. Prepare XA resource 1
      3. Commit Last Resource 1
      potential crash
      4. Log XID
      5. Commit XA resource 1
      6. End transaction

      The only way to safely support LRCO is to use the last resource as the global transaction (XID) store. If the last resource is the XID store, then the commit of the last resource and the XID become one atomic action - removing the window of opportunity for a crash between steps 3 and 4.

      The last resource is an XA transaction here is always the database - due to the performance decrease is causes on the data layer and lack of DB vendor support for it.

      To safely support the LRCO feature the JBossTS would need:

      • Automatic selection of a TX store based on which database is enlisted as the Last Resource in the transaction. One of the TX stores should be able to be flagged as the default.
      • A pluggable transaction store that allows for more than one TX Store, in the event there is more than one database configured in the container. This can be via a fa├žade that federates the stores. This is needed so that the recovery process can access all of the XIDs.
      • A more generic JDBC store implementation. The current implementation currently doesn't support many database vendors - particularly DB2 and Sybase.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                jiwils Jimmy Wilson
                Reporter:
                jiwils Jimmy Wilson
              • Votes:
                0 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: