Correct. We have 'fixed' this issue by registering with the transaction notification handler and receiving notifications for transactions being committed as opposed to trying to load the node by id to determine if it is really available.
Sent from my iPhone > On Nov 25, 2014, at 16:45, Mattias Persson <[email protected]> wrote: > > So may I sum this up as you're temporarily seeing the created node, in this > manner (assuming we have a nodeIsVisible() returning boolean: > > false > false > ... > false > true > false > true > true > ... > > and you only see this behaviour in enterprise, not community. Is that correct? > > >> On Sat, Nov 22, 2014 at 5:18 PM, Clark Richey <[email protected]> wrote: >> All, >> We have a highly concurrent custom bulk loader. When we run it using the >> community version of Neo4j 2.1.5 it executes flawlessly. When we run it >> against the enterprise version we see a race condition happening. >> >> Here is a simplified version of the workflow and what is happening: >> During our load process we create a transaction within the scope of a thread >> and within that transaction we create a node. We store the node id in an >> AtomicLong and pass that to another thread. >> >> There is another thread running (in its own transaction) that receives the >> AtomicLong from the thread the created the aforementioned node. It is >> waiting on that node to get created because it has another node that needs >> to create a relationship to that node. Because we know that the previous >> thread may not have committed the transaction in which this node was created >> (the thread is creating many nodes) we first perform a getNodeById to see if >> the node is available. If it isn’t, we essentially throw it back and come >> back to it later in the cycle. If the call to getNodeById doesn’t throw a >> NodeNotFoundException, then we know the transaction has been committed. >> Slightly later within this same thread we now attempt to retrieve that node >> by its id and we now get a NodeNotFoundException. >> >> If we pause the loader at this point, or even wait for it to finish, and >> then use the neo shell to check for the existence of the node we see that it >> exists. It wasn’t deleted (there are no deletions happening in this process >> anyways). >> >> Can someone PLEASE explain what is happening here? >> >> <pic-0.jpg> >> <pic-1.jpg> >> Clark Richey: Chief Technology Officer >> e [email protected] >> p 240.252.7507 >> This message and any included attachments are property of FactGem and its >> affiliates, and are intended only for the addressee(s). The information >> contained herein may include trade secrets or privileged or otherwise >> confidential information. Unauthorized review, forwarding, printing, >> copying, distributing, or using such information is strictly prohibited and >> may be unlawful. If you received this message in error, or have reason to >> believe you are not authorized to receive it, please promptly delete this >> message and notify the sender by e-mail. Thank you. >> -- >> 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. > > > > -- > Mattias Persson > Neo4j Hacker at Neo Technology > -- > 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. -- 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.
