neo4j locks for transactions

Question

I am just starting out with neo4j to evaluate whether it would be a good underlying database for a recommendation engine. I was wondering if there is any documentation regarding the locks obtained on entities during read and write operations.

E.g. if node N is related to nodes N1 and N2 through relationships R1 and R2 respectively, if the relationship R1 is being created or modified, will any operation that uses N, N1, N2 or R2 (maybe relationship creation/modification or traversal) encounter a block ? Intuitively, I would guess no, since it is only R1 that is being written to, and that is the only entity that should get locked. However, I guess it would also depend on the underlying implementation, especially since bidirectional traversal is offered for every relationship (maybe N and N1 would be locked ?). It would be great if someone can point me to some official documentation on this.

If such locking does indeed happen, one way I can think of to solve the problem would be to resolve each node into child nodes for each relationship purpose, each connected to the root entity. (say user is Social User, user is Product User etc.)

I guess this would allow lesser number of relationships per node, resolution of the root node into write heavy and read heavy children, and allow for quick retrieval of certain subgraphs. The only disadvantage I can see is the total number of nodes and relationships increases n times (my db size is relatively small with n=4, so i dont have a problem with that). Any input into whether these conclusions are right, and if so, if they help to improve performance and decrease the number of locks, would be greatly appreciated.

Answer 1

In your first scenario where R1 (between N and N1) is being created N and N1 will be locked with a write lock, which means that other writes to N or N1 will block, but not reads (if no read lock is issued manually before reading).

In the scenario where R1 is changed somehow (property set) only R1 is locked.

Your solution by splitting an entity into several specific-purpose sub nodes is a reasonably good one, if you observe a real problem with contention. In most occurences I've seen this used it has been a split on relationship type... something that will probably be solved by a planned feature for better handling of densely connected nodes. This feature will probably yield quite similar effects to that.