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

rethinking ISPN transactions



    • Feature Request
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • None
    • Core


      Umbrella JIRA for several transaction related improvements:
      1. Async options for commit/rollback (DONE)

      • they don't really make sense as a user you don't get any guarantee on the status of the transaction
      • they complicate the code significantly
      • I think they should be removed


      • it has the same performance as REPEATABLE_READ, but offers less guarantees.
      • unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator
      • I think it should be removed

      3. Optimistic tx without Write Skew Check (WSC)

      • well, without WSC the transactions are not optimistic by definition
      • they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee
      • suggestion: optimistic tx should always have WSC enabled (no option to configure it)
      • build our batching functionality on top of what currently is optimistic tx without WSC and document it as such

      4. Remove 1PC option

      • I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing

      5. Configuration changes

      • remove (deprecate first) write-skew attribute. it will be enabled automatically when needed to keep the data consistent
      • remove eager-locking-single-node. deprecated since 5.1 (DONE)
      • remove transaction-protocol and add TOTAL_ORDER to locking-mode. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
      • remove eager-locking. deprecated since 5.1 (DONE)
      • move isolation-level to <transaction>. it only makes sense for transactional caches.
      • remove single-phase-auto-commit ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.

      6. Internal changes

      • remove list of WriteCommand and keep a map between key and new-value, new-metadata and version-read. A null value means a remove operation.

      7. Create a single XaResource/Synchronization per cache-manager instead of per cache.

      8. For implicit transaction and auto-commit=true, if the transaction fails to commit, it can be retried until succeed. This will make the conditional operation to return a valid return value. Possible problem with retry is when a partition happens and it may fail the transaction forever.

      • note: conditional operations that return true or false doesn't need to retry the transaction. They can return false when the transaction fails.

      [1] http://markmail.org/thread/a7fjko4dyejxqgdy
      [2] https://github.com/infinispan/infinispan/pull/2177
      [3] http://infinispan.markmail.org/thread/nl2bs7rjvayjcybv
      [4] http://infinispan.markmail.org/thread/vbg6g4otu7djazbc


        Issue Links



              pruivo@redhat.com Pedro Ruivo
              mircea.markus Mircea Markus (Inactive)
              1 Vote for this issue
              3 Start watching this issue