Notes from Dean Jacobs's talk
12 use cases for how data is managed in clsutered appservers that they think cover the space well --> just need c/o stores for each type?
Read-mostly: primary copy in shared backing store, relaxed consistency
Three binary options:
RMW data: primary copy may be in appserver(!), strong consistency requirements. Eg session state - nearly every read is accompanied by a write. Many reasons to keep this data out of the DB despite strong consistency requirements.
Hybrid - 1 case. Primary managed by appserver, everyone has a replica, update from anywhere, read-mostly. Can use pessimistic locking or master that coordinates updates from slaves. Haven't found a use for this in practice; included for completeness. Usually there's a better way to do this.
Some words about ROC: minimizing recovery time isn't really needed if you can fail over, and non-Internet-facing enterprise apps don't tend to see large spikes (which would make recovery time more important). Hence, ROC isn't as relevant for cluster apps. (Of course, if your overall capacity is affected by failover, and you care about this, recovery time becomes relevant to performability/goodput.)
To execute failiover, need fencing. ie, shorten the time till when it's safe to migrate, to avoid split-brain syndrome. What he really wants is to be able to put a tight bound on the time till safe failover.