Thank you both for your input. So I implemented a multithread approach using 5 threads. My CPU was running on average at 300%. Each thread started inside a transaction call. All of the threads were performing read processes and not write ones. Each thread was querying a specific non-overlapping range of node ids. I didn't measure the performance but I felt like there was no improvement. In fact I felt that multithreading was slower. Maybe my implementation is not the optimal.
It would be nice if Neo4j guys can do some benchmarking on multithreading and share their experience. On Friday, May 16, 2014 12:11:26 PM UTC-4, Chris Vest wrote: > > > On 12 May 2014, at 20:50, Alx <[email protected] <javascript:>> wrote: > > What is the best approach here? By using the startNode and endNode I could > separate the threads to avoid conflicting issues. Should I call multiple > threads inside the 'tx' transaction? Are there any examples with > multithreading in Neo4j that I can look up? I would appreciate any help. > > > Transactions are thread-bound, so each thread will have to start their own > transaction. If two threads write to the same node or relationship, then > you run the risk of your transactions being killed with a deadlock. So if > that’s a risk, then you might want to have your threads coordinate their > work such that this never happens. I wrote a stress test once, where I used > a ConcurrentHashMap of node ids to make sure that no two worker threads > operated on the same node at a time. > > The drawback is that you loose the atomicity of a transaction, when split > your traversal into multiple transactions. > > On 15 May 2014, at 23:59, Christopher Scott <[email protected]<javascript:>> > wrote: > > *I am assuming* that one can read one Node or Relation while writing to > another without lock contention (i.e. locks are at the Node and Relation > level); it would be nice to get a clear answer on this. > > > There are locks on nodes, relationships and on something called an index > entry. There is also a lock for the schema; for when creating and dropping > indexes and constraints. These locks are held until your transaction is > either committed or rolled back. > > -- > Chris Vest > System Engineer, Neo Technology > [ skype: mr.chrisvest, twitter: chvest ] > > > > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
