In my talks, I’m using a short example that illustrates how the mechanics of my notebook-driven approach for analyzing software systems works. Here you can now find another example on my blog, too. This time, it’s a notebook that uses the Cypher notebook extension to communicate with a Neo4j graph database instance to query for a typical beginners error regarding race conditions. Have also a look at the original on GitHub (best viewed in desktop mode).
In the recent stress test of our application GlugiZP2000, we had severe issues with data quality and program failures. After an initial inspection of our code review team, we found several spot in the application that can lead to race conditions.
Race conditions are bad because they lead to weird behavior in multi-user applications. Wikipedia defines Race Conditions as follows:
A race condition or race hazard is the behavior of an electronics, software, or other system where the output is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when events do not happen in the order the programmer intended.
Some of the occurred race conditions could be statically identified by our software expert John Doe. In the following analysis, we use jQAssistant and the Neo4j graph database to spot even more possible problems with the help of structural code analysis. For this, we read in the complete Java code of GlugiZP2000 into the Neo4j database.
With the following Cypher queries, we can spot some kind of race conditions that are declared public and not static fields and are written by some methods.
EXISTS(f.static) AND NOT EXISTS(f.final)
c.name as InClass,
m.name as theMethod,
w.lineNumber as writesInLine,
f.name as toStaticField
There are some possible race conditions regarding static, written Java field references. Our suggestion is to fix these immediately.