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

Write Skew check must be performed only in the primary owner

This issue belongs to an archived project. You can view it, but you can't modify it. Learn more

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 6.0.0.Final
    • 6.0.0.Final
    • Transactions
    • None

      The following case can create data inconsistency:

      A: txA reads k with version v1 and writes on k (say valueA)
      primary-owner of k: txA acquire lock on k, validates and return v2 (increment(v1))
      non-primary-onwer of k: txA registers a backup lock, validates and returns v2 (increment(v1))

      A: txA commits with version v2.
      primary-owner of k: applies txA //commit in the non-primary-owner is delayed

      B: txB remote reads k with version v2 and writes on k (say valueB) and prepare the transaction
      primary-owner of k: txB waits until the lock is relased.
      non-primary-onwer of k: txA registers a backup lock, validates and returns v2 (increment(v1), because it has not applied the txA)

      primary-owner of k: lock is release, txB is validated and it return v3 (increment(v2))

      B collects all the response and merge them. However, the map.value() can return first the response from primary-owner (v3) and them the response from the non-primary-owner (v2). The result version map will be k=>v2.

      txB will update k with the same previous version and a different value. from here the data will become inconsistent.

              pruivo@redhat.com Pedro Ruivo
              pruivo@redhat.com Pedro Ruivo
              Archiver:
              rhn-support-adongare Amol Dongare

                Created:
                Updated:
                Resolved:
                Archived: