Question

I’m using Neo4j in a concurrent environment and I have graph that looks like this:

Each item can be in none or at most one of 3 states (S1, S2 and S3). An item can change its state and the flow goes this way: item is not present in any state, then S1, S2 and finally S3.

This means that when adding an item I will have to check whether it’s already present in S1, S2 or S3. If it is, then I shouldn’t add it again. Additionally, if the item is in S1 and is requested to go to the next state in the flow then the item must be first removed from S1 and then added to S2.

Having an index on each of the states wouldn’t solve this issue because all of these operations must happen atomically as it is a concurrent environment. I’ve checked this link and I could only think about going for the Pessimistic locking approach. The pseudocode to add a new item, based on the example, should be something like:

search for node in all states
if node is present in any state
    return node
else
    begin transaction
        get a write lock on #lockNode#
        create node
        add node to initial state
    commit
    return node
end

The pseudocode to change from a state to another state should be very similar to the previous one.

So the questions are:

1. What is #lockNode# in my pseudocode? I can’t figure it out from the example. Sounds like it similar to a synchronized (lockNode) {} but I need a little exaplanation to go on with this solution
2. What would be the impact of using the reference node as #lockNode#?
3. Is it possible to atomically and in a sychronized way perform the searches in the three indexes and then add/move the node to a state?

I could easily solve this by using Java synchronization but the documentation clearly states this should not be done. Any help for a Neo4j newbie like me would be appreciated.

Answer 1

As an item can only be in one state, you can have only one index and use the “Get or create” technique in the link you provided. To know the state of an item you can traverse the dingle relationship then the state node. Or you can index using 2 properties (name & state). Or have 4 indexes

Locking the reference node will create a bottleneck (a bit less if you lock only the s1 node), and for unique node creation I think the best way is the get-or-create thing, I don’t know any other good way

Synchronization is also a big no-no as it can “conflict” with the neo4j internal locking system and create dead-locks