[infinispan-dev] Issue about propagation of the RollbackCommand in Infinispan 5.2.0

[Sebastiano Peluso]

On 8/18/12 4:55 PM, Pedro Ruivo wrote:
> On 08/18/2012 02:23 PM, Sebastiano Peluso wrote:
>> On 8/18/12 3:14 PM, Pedro Ruivo wrote:
>>> Hi,
>>>
>>> see inline.
>>>
>>> Cheers
>>> Pedro
>> (...)
>>> My 2 cents if the following:
>>> mark the transaction "as prepared" when the prepare reaches the
>>> ReplicationInterceptor and, when the rollback command is created, send
>>> this information with it.
>>>
>>> Each node, when received the rollback command, check this information:
>>> 1) if it is marked "as prepared", waits for the prepare (or do other
>>> stuff, e.g. mark the remote transaction as rollback only, ignore the
>>> prepare when received and unlock possible locked keys)
>>> 2) if it is not marked "as prepared", unlock possible locked keys
>> I've already implemented a solution like this ;-) .
>> But you can do better: you can simply avoid to send the rollback
>> messages that trigger your point 2). In this way you avoid unnecessary
>> flooding of the network. Do you agree with me?
> it depends. if you use the Pessimist Locking, the locks are acquired in
> every node. So, you must send the rollback even if you didn't send the
> prepare to unlock them.
> If you use the Optimistic Locking, I agree 100% with you =)
:-) . Yes, at the beginning of this thread I've specified that I was 
referring to the Optimistic locking scheme.
>> Thanks for you reply Pedro.
>>
>> Cheers,
>>
>>       Sebastiano
>>>> Thank you for the reply.
>>>>
>>>> Cheers,
>>>>
>>>>          Sebastiano
>>>>
>>>> [1] https://issues.jboss.org/browse/ISPN-2081
>>>>