2011/8/19 Tuure Laurinolli <[email protected]> > > On Aug 19, 2011, at 07:57 , David Rader wrote: > > > It looks like the HA implementation is for eventual consistency, tunable > by how often a slave polls the master for updates from other nodes. > > > > With a load balanced cluster, is the best practice to simply use sticky > sessions on clients to ensure that immediate reads of updated data are > served by the same node that wrote the update and are therefore consistent? > Any other recommended approaches? > > If your goal is HA, there are two other approaches: > > 1) Always read from master > > and > > 2) Always take read lock on things you read > > Always reading from master works because writes are synchronously > replicated to master, and taking a read lock works because taking a read > lock always synchronizes with master (although it of course also disallows > related writes for the duration of your transaction). These solutions affect > write performance (reading from master consumes master capacity, and taking > read locks prevents other transactions from completing). Read performance is > certainly affected as well compared to sticky sessions, and is likely to be > considerably lower because of the synchronization requirements, and load on > master. > > Consistency guarantees would be as follows: > > - Reading from arbitrary slaves guarantees very little > - Sticky sessions guarantee read-everything-up-until-your-previous-write > - Reading from master guarantees consistency re: communications over side > channels (if another node, after committing, tells you that he wrote > something, you can see that write, or possibly some newer write) > - Taking read locks guarantees > read-everything-up-until-your-previous-lock-request and also repeatable > reads >
Taking read locks on everything is a bit overkill and will probably only be necessary in certain scenarios. Pulling updates and then do a read request will make that read request view a snapshot of the latest or near-latest graph. > > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > -- Mattias Persson, [[email protected]] Hacker, Neo Technology www.neotechnology.com _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
