On Mon, Feb 13, 2012 at 2:49 PM, Bela Ban <bban(a)redhat.com> wrote:
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.
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.
Not if we use the RemoteCacheStore... A cache store is only called
during commit + HotRod doesn't support transactions.
So I believe option #2 can also support only async replication between sites.