Hi, Right now we support DLD in the following scenarios: local caches, symmetric tx that create deadlocks over two replicated caches (symmetric in the sense that A replicates to B and B replicates to A at the same time). In the case of distribution (replication as well, especially async one) there might still be a deadlock if both A and B replicate to C, but they replicate transactions that would result in deadlocks, so deadlock would result in C. Let's take an example, A wants to replicate Tx1 that affects (key1, key2) in this sequence. B wants to replicate Tx2 that affects (key2, key1) in this sequence. While replicating on C, Tx1 and Tx2 would result in a deadlock (classic scenario). Now a simple way of solving this (if I'm not missing something!!) is to order the keys in the replicated transaction based on some criterion (e.g. lexicographic) and apply them in the same sequence: Tx1(key1,key2) and Tx2(key1, key2). This will avoid deadlocks -> increase throughput. Now, at the core of this approach is the fact that the order of operations in the transaction is not relevant - which does not stand in current implementation. E.g. let's say we have a tx that does (remove(key), put(key, 'otherVal')). If we change the order result is totally different - not good! A way to avoid this (and to also reduce the amount of replication, by compacting changes by key) is to keep the modifications in a Map<key,Modification>. For each key we keep only the last value set within it, so if we modify the same key 1000 times within a tx we only replicate last modification vs current approach where 1000 operations are replicated. If a key is deleted, we still keep it in the map, with a marker for deletion. This way we only replicate the delta of modifications, and the order of operations is no longer relevant, so that we can leverage previously described deadlock detection. The advantages of this would be higher throughput by reducing the chance of 'asymmetric' deadlocks (A,B encounter a deadlock while replicating on C) and possible reduction in the size of the transaction (if it has multiple operations on the same key). The drawback is mainly the fact that some additional computation needs to be made to manage the map content (not a lot I reckon, instead of a List.add we'll do an map.get() + map.put(), for each modification within the transaction). Wdyt? Cheers, Mircea