Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-5623

Retried prepare commands do not wait for backup locks

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 8.1.0.Final
    • 7.2.3.Final, 8.0.0.Beta1
    • Core
    • None

    Description

      When the primary owner crashes during prepare, the prepare command is retried on the new primary owner. But because the transaction topology id stays the same, the new primary owner does not check for backup locks owned by other transactions from the previous topology.

      That makes it possible for the retried prepare command to lock a key that was already locked by another transaction on the primary owner.

      This wasn't a problem before the ISPN-4546 fix, because a primary owner crash would have forced the transaction to roll back.

      Attachments

        Issue Links

          causes

          Bug - A problem that impairs or prevents the functions of the product. ISPN-6518 org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly

          • Critical - To be worked on immediately following BLOCKER issues.
          • Closed

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-4624 org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly

          • Critical - To be worked on immediately following BLOCKER issues.
          • Closed

          Bug - A problem that impairs or prevents the functions of the product. ISPN-6047 Deadlock when a prepare command is retried

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-4623 Deadlock when a prepare command is retried

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Activity

            People

              pruivo@redhat.com Pedro Ruivo
              dberinde@redhat.com Dan Berindei (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: