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

Read only caches are also added as transaction resources

    Details

    • Type: Enhancement
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Rejected
    • Affects Version/s: 5.1.1.FINAL
    • Fix Version/s: None
    • Component/s: Transactions
    • Labels:
      None

      Description

      When read only caches are participating in the transaction , tehy are added to resource list. Can this be optimized ?

        Gliffy Diagrams

          Activity

          Hide
          mircea.markus Mircea Markus added a comment - - edited

          As expected, Infinispan doesn't do any remote calls in the case a transaction is read-only. That means that the calls the TxManager performs against the registered XAResource (or Synchronization) are in-memory only - and they should be very cheap. On top of that, when registered as an XAResource, ISPN signals the TM that a TX is read-only, so the commit(2nd phase) call shouldn't even be performed on any decent TM.

          Also thinking about the implementation, the only way in which this optimization can be implemented is by enlisting infinispan in a transaction only during the first write (or read that has Flag.FORCE_WRITE_LOCK). But this doesn't work for the general case: if write skew check is enabled and we have the following sequence:

          - tx.start()
          - read(a)
          - write (a) //here is where the tx is enlisted
          - tx.commit()
          

          During the commit time, the write skew check is not performed correctly as the tx is not aware of the initial read.

          Given the restricted scope of this optimization and the fact that this won't bring any real performance improvements (but avoid a single in-vm cheap method call) I don't think this makes sense as it would complicate the code significantly.

          On top of that, if the user doesn't want the get to be transactional, it should suspend the running transaction and resume it after the get completed.

          Show
          mircea.markus Mircea Markus added a comment - - edited As expected, Infinispan doesn't do any remote calls in the case a transaction is read-only. That means that the calls the TxManager performs against the registered XAResource (or Synchronization) are in-memory only - and they should be very cheap. On top of that, when registered as an XAResource, ISPN signals the TM that a TX is read-only, so the commit(2nd phase) call shouldn't even be performed on any decent TM. Also thinking about the implementation, the only way in which this optimization can be implemented is by enlisting infinispan in a transaction only during the first write (or read that has Flag.FORCE_WRITE_LOCK). But this doesn't work for the general case: if write skew check is enabled and we have the following sequence: - tx.start() - read(a) - write (a) //here is where the tx is enlisted - tx.commit() During the commit time, the write skew check is not performed correctly as the tx is not aware of the initial read. Given the restricted scope of this optimization and the fact that this won't bring any real performance improvements (but avoid a single in-vm cheap method call) I don't think this makes sense as it would complicate the code significantly. On top of that, if the user doesn't want the get to be transactional, it should suspend the running transaction and resume it after the get completed.
          Hide
          sudheerk84 Sudheer Krishna added a comment -

          Its not actually a single call, it depends on the number of caches read in the transaction. (Also I am not sure if there can be there be any commit/prepare optimizations)

          For example we had transactions where actually there was only a single write as part of transaction, and there were read operations from five caches. This resulted in registering all these read caches and sending corresponding responses during prepare and commit also.

          Show
          sudheerk84 Sudheer Krishna added a comment - Its not actually a single call, it depends on the number of caches read in the transaction. (Also I am not sure if there can be there be any commit/prepare optimizations) For example we had transactions where actually there was only a single write as part of transaction, and there were read operations from five caches. This resulted in registering all these read caches and sending corresponding responses during prepare and commit also.
          Hide
          mircea.markus Mircea Markus added a comment -

          @Sudheer indeed the number of calls is proportional to the number of caches read in the transaction. My point is though that for each of these caches, the call should be cheap: in memory, no RPCs involved. This change is relatively complex and it wouldn't bring any relevant performance improvement.

          Show
          mircea.markus Mircea Markus added a comment - @Sudheer indeed the number of calls is proportional to the number of caches read in the transaction. My point is though that for each of these caches, the call should be cheap: in memory, no RPCs involved. This change is relatively complex and it wouldn't bring any relevant performance improvement.
          Hide
          galder.zamarreno Galder Zamarreño added a comment -

          Not a bug. We added a test to verify it.

          Show
          galder.zamarreno Galder Zamarreño added a comment - Not a bug. We added a test to verify it.

            People

            • Assignee:
              mircea.markus Mircea Markus
              Reporter:
              sudheerk84 Sudheer Krishna
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development