Infinispan
  1. Infinispan
  2. ISPN-1877

Read only caches are also added as transaction resources

    Details

    • Type: Enhancement Enhancement
    • Status: Resolved Resolved (View Workflow)
    • Priority: Major Major
    • Resolution: Rejected
    • Affects Version/s: 5.1.1.FINAL
    • Fix Version/s: None
    • Component/s: Transactions
    • Labels:
      None
    • Estimated Difficulty:
      Medium
    • Similar Issues:
      Show 10 results 

      Description

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

        Activity

        Hide
        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
        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
        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
        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
        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
        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 Zamarreño
        added a comment -

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

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

          People

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

            Dates

            • Created:
              Updated:
              Resolved: