[ https://jira.jboss.org/jira/browse/ISPN-262?page=com.atlassian.jira.plugi... ] Tero Heinonen commented on ISPN-262: ------------------------------------ Excellent, just to add comments as of the requirements/scenarios/use cases: Overall requirements: SENDER - listen all changes (also those not currently partitioned in the sender node) in the cluster - queue the changes - remove redundant older changes from the queue (either at the time of adding to the queue or at sending) - compress/encrypt transmission as needed - configurable packet size for transmission (not referring to IP packet size/fragmentation, but application level to manage with really bad transmission paths) - transaction information would not be needed to be transmitted (except that no uncompleted transaction would ever be sent, even if the SENDER node is the source of the transaction) - after some thinking, I'd prefer to keep this separated from StoreLoader/StoreSaver, as the use patterns are quite different, would be better as a new class Distributor etc. RECEIVER - receive and acknowledge transmissions from the SENDER - queue changes - put changes into the local cluster in accordance with conflict resolution policy (see below) Possible conflict resolution policies: 1. ownership based (one-way) distribution, SENDER is always right, all transmitted changes are implemented 2. time-stamp based (one-way/two-way) distribution, the information with later timestamp is right (requires of course quite good time sync between the clusters, and assuming ms resolution, would not guarantee any absolute order), can be configured either one-way, or two-ways 3. user-definable ConflictSolver class/method -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira