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

[Mircea Markus]

----- Original Message -----
> From: "Bela Ban" <bban at redhat.com>
> To: infinispan-dev at lists.jboss.org
> Sent: Monday, February 13, 2012 12:49:56 PM
> Subject: Re: [infinispan-dev] X-datacentre replication: design suggestions
> 
> 
> 
> On 2/13/12 12:22 PM, Sanne Grinovero wrote:
> 
> > 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.
> 
> 
> This use case cannot be supported by option #3 AFAICS: the bridge
> between LON and SFO is completely asynchronous and doesn't know
> anything
> about sync or async RPCs, so TX2 can be applied in SFO before TX1.
Why can't the bridge send the messages in the order in which they were enqueued?

> 
> With option #2, if you run with SYNC, then the TX1 will complete
> before
> TX2 is started. Unless, of course, the 2 transactions are started on
> different nodes: then,  it depends on which TX acquires the locks
> first,
> but this is the same behavior as in a local cluster.
> 
> Hmm, how does option #3 handle TXs anyway ? Does a PUT on B and C not
> trigger anything until the TX has been completed successfully, and
> then
> we forward the outcome of the TX to A, which forwards it to X ? 
That's what i have in mind. 

> How does
> X then apply it ? Special operation or a set of PUT and REMOVES ?
The simplest approach is for X to starts a tx, run all the ops and commit it. A more advanced apprach is for X to determine, based on the key set, which scenarios node is the most appropriate to run the tx and delegate run of the transaction to the given node. Actually the second approch can be easily implemented through a distriuted executor.