We're already writing to the master. What do you mean by "with appropriate locks"? We're using Cypher over REST hitting the transactional endpoints as documented at:
http://docs.neo4j.org/chunked/stable/rest-api-transactional.html I don't see anything documented there to allow obtaining of any kind of lock over the REST API. We are not using MERGE, will use that and update this thread. Thanks. ---- Saad On Tuesday, September 16, 2014 5:31:27 PM UTC-4, Michael Hunger wrote: > > Also I recommend that you focus writing to the master and not the slaves > for higher performance. > > Feel free to raise a support ticket with our Neo Technology customer > account when the issue persists with MERGE > > On Tue, Sep 16, 2014 at 11:29 PM, Michael Hunger < > michael...@neotechnology.com <javascript:>> wrote: > >> To assure uniqueness across multiple threads and a cluster (with >> appropriate locks, please use MERGE) >> >> MERGE (n:SEGMENT {segmentId : 110484}) ON CREATE SET n.name = "name" , >> ....; >> >> >> On Tue, Sep 16, 2014 at 11:15 PM, Saad Mufti <saad....@gmail.com >> <javascript:>> wrote: >> >>> Hi, >>> >>> We have a Neo4J 2.1.3 database and we have a uniqueness constraint that >>> was created as follows: >>> >>> CREATE CONSTRAINT ON (segment:SEGMENT) ASSERT segment.segmentId IS UNIQUE >>> >>> When we test this from the browser, it works fine in detecting >>> violations, e.g: >>> >>> CREATE (n:SEGMENT {name : "duplicate", segmentId : 110484}) RETURN n >>> >>> results in >>> >>> Node 589 already exists with label SEGMENT and property "segmentId"=[110484] >>> >>> Neo.ClientError.Schema.ConstraintViolation >>> >>> which is fine. >>> >>> We have a load tester setup with 3 machines and multiple threads per >>> box using Cypher over REST talking to Neo4J and using the transactional >>> endpoints to do creates similar to above (but of course many more >>> properties relevant to our app), and always writing to the Neo4J master in >>> an HA setup. >>> >>> We can reliably reproduce in that setup multiple violations of the >>> uniqueness constraint that are NOT caught by Neo4J, they execute without >>> error and in the resulting db we can see multiple nodes with the SEGMENT >>> label and the same value for the segmentId property (we are intentionally >>> generating duplicate segmentId values for our test). >>> >>> Anyone else run into the same issue? Is this a Neo4J bug? >>> >>> Thanks. >>> >>> ----- >>> Saad >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Neo4j" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to neo4j+un...@googlegroups.com <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to neo4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
