[CASSANDRA-12295] Double check locking pattern

• Type: Sub-task
• Status: Open
• Priority: Normal
• Resolution: Unresolved
• Component/s: Legacy/Local Write-Read Paths
• Assignee: Unassigned
• Reporter: Eduardo Aguinaga
• Created: 26/Jul/16 14:13
• Updated: 16/Apr/19 09:30

Description

Overview:
In May through June of 2016 a static analysis was performed on version 3.0.5 of the Cassandra source code. The analysis included an automated analysis using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools Understand v4. The results of that analysis includes the issue below.

Issue:
The file ketspace.java includes a double check locking pattern. The double check locking pattern is an incorrect idiom that does not achieve its intended effect.For more information see LCK-10J in the CERT Oracle Coding Standard for Java https://www.securecoding.cert.org/confluence/display/java/LCK10-J.+Use+a+correct+form+of+the+double-checked+locking+idiom

The snippet below shows the double check locking pattern:
Keyspace.java, lines 115-135:

115 private static Keyspace open(String keyspaceName, Schema schema, boolean loadSSTables)
116 {
117     Keyspace keyspaceInstance = schema.getKeyspaceInstance(keyspaceName);
118 
119     if (keyspaceInstance == null)
120     {
121         // instantiate the Keyspace.  we could use putIfAbsent but it's important to making sure it is only done once
122         // per keyspace, so we synchronize and re-check before doing it.
123         synchronized (Keyspace.class)
124         {
125             keyspaceInstance = schema.getKeyspaceInstance(keyspaceName);
126             if (keyspaceInstance == null)
127             {
128                 // open and store the keyspace
129                 keyspaceInstance = new Keyspace(keyspaceName, loadSSTables);
130                 schema.storeKeyspaceInstance(keyspaceInstance);
131             }
132         }
133     }
134     return keyspaceInstance;
135 }