[infinispan-dev] TOM
Bela Ban
bban at redhat.com
Fri Mar 23 09:12:03 EDT 2012
Hi Pedro,
I'm currently looking at your TOM protocol (GROUP_MULTICAST).
I have a couple of points to discuss:
#1 We need to find a better package name for org.jgroups.protocols.pmcast
#2 We also need to find a better name for the protocol GROUP_MULTICAST.
In JGroups, we call a message to a single cluster member a *unicast*, a
message to all cluster members a *multicast* and a message to a subset
of the cluster members an *anycast*. So I guess both the package name
and the protocol name should have something to do with "totally ordered"
and "anycast"...
How about
- TOA (Total Order Anycast) ?
- TOPR (Total Order for Partial Replication) ?
- TOS (Total Order for a Subset) ?
-
Thoughts / suggestions ?
#3 I assume your changes to Infinispan involve sending a 1-phase
PREPARE/COMMIT message to N members (who own the keys touch by the TX).
In Infinispan, this is done via (IIRC) N unicasts, or - if this was
changed in the meantime - by an *anycast*.
Say we have to send the 1PC PREPARE message to {A,C,D,E}. So this would
be 4 unicasts (to A, C, D and E) or an anycast to the target set
{A,C,D,E}. The latter will result in 4 unicasts, like the former.
The way we could do that is to have Infinispan pass the target list
{A,C,D,E} to RpcDispatcher.callRemoteMethods() as targets. Also,
Infinispan would have to use a new option (e.g.
use_total_order_anycast). When this flag is set, in
RequestCorrelator.sendRequest(), we'd create a GroupAddress={A,C,D,E}
and send a new Message with the GroupAddress as destination down the stack.
The new protocol would then see that the Message.dest is a GroupAddress
and handle the message (not passing it further down, as the other
protocols can't handle GroupAddresses).
Is this the change you made in your prototype used in the paper
"Exploiting Total Order Multicast..." to run the benchmarks, comparing
TOM to 2PC ?
--
Bela Ban, JGroups lead (http://www.jgroups.org)
More information about the infinispan-dev
mailing list