2.0 / snapshot - merge is not thread safe / transactional

[mybyte]

It seems that when firing a lot of batch queries via REST API, they cause two issues:

1. Double entries

In a multithreaded environment, firing a couple of queries such as:

merge (x:Website {key:"google.com"}) 
merge (y:Application {key:"google reader"})
create unique x-[:`has application']-y

will produce double entries.

2. Some operations seem to be relying on iterating over node id's
   It seems that during batch jobs, nodes are created temporarily. Some queries fired in parallel to batch jobs seem to include those e.g.:

start n=node(*)
with labels(n) as lbl
where length(lbl)<>0
return distinct lbl;

Will very often produce an error such as:
No node with id 9102 found.

It seems that selectors matching all nodes (node(*) or match n) would always include nodes that are temporary (no idea how this can happen, does merge temporarily create nodes?) and following operating fail when they disappear during processing...

[freeeve]

This should be closed now with 2.0's release, although it's worth noting that you need a unique constraint to ensure uniqueness with MERGE.

[jakewins]

+1, this is resolved

[tugberkugurlu]

I am potentially seeing the same issue: http://stackoverflow.com/questions/34302176 I created a unique constraint but that caused me to receive deadlock errors like below:

"DeadlockDetectedException: LockClient[31] can't wait on resource RWLock[INDEX_ENTRY(49), hash=2045111578] since => LockClient[31] <-[:HELD_BY]- RWLock[NODE(980), hash=779731960] <-[:WAITING_FOR]- LockClient[25] <-[:HELD_BY]- RWLock[INDEX_ENTRY(49), hash=2045111578]"

[tugberkugurlu]

It seems like DeadlockDetectedException is the expected behaviour in these situations. However, if it will throw in Merge cases + I should create a unique index to ensure the uniqueness + I should also be the one to handle this error in my application, what is the use of MERGE then?