TT bi-directional general workload architechture with 3 nodes

Question

Hello Experts,
We are starting a new project where we will have a cluster with 3 nodes. We will have both our application and TT running on each node.
Then we will have a switch doing the application load balancing between the 3 nodes of the cluster. Whenever a request reaches one of the cluster nodes, the application queries/updates the local TT installed in the same node. All the changes made in one of the TT instances must be immediately replicated to the other 2 nodes.
My questions are:
1) Does TT supports a 3 nodes bi-directional general workload architecture?
2) According to the documentation, a bi-directional general workload configuration should not be used with the return twosafe return service. Can we use the bi-directional general workload configuration (on a 3 nodes cluster) with a return receipt configuration?
3) Since we can not use the return twosafe configuration with the bi-directional general workload architecture, how long (in avarage) dos it take for an update in one of the 3 TT instances to propagate to the other 2 instances ?
Thanks in advance,
Marcos Ortiz

Answer 1

Hi Michael,
1. Yes, TimesTen supports a three node multi-master general workload architecture. However, we absolutely do not recommend use of such an architecture as it has many inherent dangers. You will almost certainly suffer from datastroe divergence with such an architecture and also recovery of a failed datastore back to a state consistent with the othyer datastores will be extremely difficult. I owuld urge you to consider alternative architectures that do not require N-way mult-master where N > 2 (and even then you must enforce strict workload partitioning to ensure that consistency is maintained).
2. You cannot use RETURN TWOSAFE with multi-master since you will almost certainly encounter distributed deadlocks which TimesTen does not detect nor resolve. You can use RETURN RECEIPT in multi-master configurations but of course this offers a lower level of assurance than twosafe.
3. It is impossible to give some specific figure for how long it takes for replication to occur with RETURN RECEIPT since there are many variables. Typically replication occurs within a few milliseconds, dep[ending on configuration, but any number of factros such as sudden high system load, network glitch etc. etc. can cause it to take significantly longer. All you can say for sure is that if a commit using RETURN RECEIPT returns succesas then the replicated data has arrived at the remote datastore and is in the 'apply queue'.
Without wishing to labour the point, the architecture you are considering is highly problematic and is one we strongly recommend customers avoid. Using conflict resolution is not a solution as it cannot detect or resolve all possible conflicts and you swill still have divergence and recovery issues.
Chris