Re: [infinispan-dev] X-datacentre replication: design suggestions
----- Original Message -----
From: "Bela Ban" <bban(a)redhat.com>
To: infinispan-dev(a)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.