On Nov 2, 2011, at 13:33 , Balazs E. Pataki wrote:
Hi,
I had a similar issue (also with ID generation), and I would be also
interested in a solution, or how synchronizations should be done to
avoid deadlocks like this in the transaction.
Have you considered using IDs that can be
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
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
On Aug 12, 2011, at 20:40 , Tuure Laurinolli wrote:
Updates will however propagate from the master to other slaves eventually so
a write from one slave is not immediately visible on all other slaves.
It sounds like eventual consistency from master to other slaves. if so, I
am interested
On Aug 15, 2011, at 18:18 , Tuure Laurinolli wrote:
On Aug 12, 2011, at 20:40 , Tuure Laurinolli wrote:
Updates will however propagate from the master to other slaves eventually so
a write from one slave is not immediately visible on all other slaves.
It sounds like eventual consistency
Hello,
I read through the HA/replication documentation at
http://docs.neo4j.org/chunked/stable/ha.html but a few question about possible
failure modes remains: Can a HA transaction fail after it's committed on
master? Consider the following: client C1 commits transaction T through slave
S1,
6 matches
Mail list logo
