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 gene
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
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 e
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 othe
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 oth
On Aug 11, 2011, at 23:26 , dhsieh wrote:
> According to http://docs.neo4j.org/chunked/stable/ha-architecture.html, this
> is my understanding and I would like for confirmation from Neo4j:
>
> A slave will handle writes by synchronizing with the master to preserve
> consistency.
>>> It sounds l
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, wh
7 matches
Mail list logo
