2011/8/23 Tuure Laurinolli <tuure.laurino...@portalify.com> > > On Aug 23, 2011, at 17:30 , Mattias Persson wrote: > > >> Hm, actually client X can't read anything touched by T from master, > since > >> slave A will have taken write locks on things it modifies, and the write > >> locks are associated with T that never finishes in this example. Still, > >> master's state will diverge from cluster state. > >> > >> > > It's ok to read things that are held by write locks, reads will not > block. > > Hm, so to have safe replication with the scheme I described, readers would > also need to take read locks on the items they read even if they don't plan > to update anything based on the results. Then again, if read locks are taken > like that, the client may as well read from any slave, since read lock > causes state to be synchronized from master.
read locks aren't taken during normal operation so just doing a traversals or similar won't grab read locks. Pulling updates and then doing a traversal will make sure it's performed on a consistent snapshot, if no write operations or lock-grabbings are performed during. > > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
