[infinispan-dev] X-datacentre replication: design suggestions

[Sanne Grinovero]

On 13 February 2012 11:07, Mircea Markus <mmarkus at redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Sanne Grinovero" <sanne at infinispan.org>
>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>> Sent: Monday, February 13, 2012 8:06:03 AM
>> Subject: Re: [infinispan-dev] X-datacentre replication: design suggestions
>>
>> On 10 February 2012 19:17, Dan Berindei <dan.berindei at gmail.com>
>> wrote:
>> > Mircea was saying that we'd only send over committed modifications,
>> > so
>> > no locking RPCs that need to be synchronous.
>>
>> I understand the performance cost would be otherwise high, but is
>> this
>> not defeating the purpose?
>> I would expect as a user that - if I need cross-datacenter
>> replication
>> - I would get a strong guarantee that committed data is safe in both
>> locations, not that some might still need to be sent.
> If you configure an *sync* bridge then you'd get the confirmation during the commit. What you don't get by participating in the preapre is consistency guarnatees for two tx writing to same data in different datacenters - but not sure we want to support that?
>
>> So I would expect that - for transactional operations only - the
>> other
>> locations participate in the prepare phase.
>> If we go for async replication, won't we need as well some way to
>> guarantee that the other replicas apply changes in the correct order?
> Can you please detail on this scenario?

I have two transactions, run in sequence:
- TX1 updates A
- TX2 deletes A

If you send them both in async to the other datacenter, you'll have to
make sure they are not reordered. I know JGroups can provide that
guarantee, just wondering if it's the plan to do this via JGroups, or
if we have an own buffer that we can still guarantee the order, or
even better merge changes on the same keys like we do with the async
CacheStore.