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.
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 ? How does
X then apply it ? Special operation or a set of PUT and REMOVES ?
--
Bela Ban
Lead JGroups (
http://www.jgroups.org)
JBoss / Red Hat