1 Reply Latest reply on Jul 10, 2012 6:31 AM by galder.zamarreno

    How works asynchronous replcation and optimistic transactions in combination

    hackland

      Hello again,

       

      for me it is not clear what happens if I use "asynchronous replcation" and "optimistic transactions" in combination.

       

      1. This combination must be slower then "Invalidation asynchronous" and "optimistic transactions". Is this right?

       

      2. Then i have a transaction that update or put a new data in the cache. I get the locks at the prepare phase at begining of commit() is this correct?

      Do i get the locks for all the replicas in the cache at this point or only for one data item?

      3. When commit() is successful only one data is written and later it would replicate to the others because of "asynchronous replication"?

      4. For example I have data x. Data x has two replicas. The value from x = 5. So if two transactions work on x at the same time. One on one replica and the other on the other replica.

      Both change the value at the same time. Transaction 1 read the value 5 and would like to change it to 6. Transaction 2 reads 5 and would like to change it to 7. Ist this possible? Because of MVCC it is possible or?

      5. Can the system recognise the conflict?

      6. If changing the configuration to pessimistic transaction can then the system recognise the conflict?

      7. Is this combination only recomended then i don't change data in the cache?

       

      Thanks a lot and sorry for my bad english!

       

      Best regards

       

      Andy

        • 1. Re: How works asynchronous replcation and optimistic transactions in combination
          galder.zamarreno

          Re 1. Slightly slower because with replication it needs to serialize the key and the value, before doing a fire-and-forget to the network in prepare. With invalidation, only the key needs to be marshaller.

          Re 2. We implemented single lock ownership, so the locks are aquired in a single node, but all nodes aquire the locks on a specific node depending on the key.

          Re 3. Apply locally and send it to the other nodes in fire-and-forget style

          Re 4. As long as you use REPETEABLE_READ and have writeSkew enabled and you use transactions, that conflict will be discovered. However, if this is likely to happen in your system, I would recommend against using asynchronous modes.

          Re 5. Yes, see previous point.

          Re 6. It's independent of PL or OL.

          Re 7. Which combination?

          1 of 1 people found this helpful