Hello, Mayur.  This looks like *very* valuable information and I for one 
appreciate you using Derby as a test bed for your work.

It would be great to create a JIRA bug item for these race conditions 
(I'm not sure if one item per race is overkill or not), and yes, 
definitely we'd like to see more of this.

Is this tool something that could be run on a regular basis and provide 
reports?  It is likely that new race conditions could get introduced as 
new code is submitted...

Thanks,

David

Mayur Naik wrote:
> 
> Hello,
> 
> I'm not sure if this is the right mailing list to post this.  I'm a PhD 
> student in Computer Science at Stanford University and I'm evaluating a 
> static race detection tool I've developed on open source programs.  I 
> ran it to check the implementation of the java.sql.Connection interface 
> in Derby and found 76 races, see:
> 
> http://suif.stanford.edu/~mhn/db-derby-10.1.1.0-src/connection_test/paos3/index.html

> 
> 
> The races are due to 12 missing synchronization's in
> 
> org/apache/derby/client/am/Connection.java
> 
> In particular, the following methods need to be synchronized:
> 
> boolean getAutoCommit()
> boolean isClosed()
> int getTransactionIsolation()
> java.sql.SQLWarning getWarnings()
> java.sql.DatabaseMetaData getMetaData()
> boolean isReadOnly()
> String getCatalog()
> java.util.Map getTypeMap()
> int getHoldability()
> java.sql.PreparedStatement prepareStatement(String, int)
> java.sql.PreparedStatement prepareStatement(String, int[])
> java.sql.PreparedStatement prepareStatement(String, String[])
> 
> Lack of synchronization in these methods can lead to unexpected 
> behavior, for instance, the race:
> 
> http://suif.stanford.edu/~mhn/db-derby-10.1.1.0-src/connection_test/paos3/R432_trace.html

> 
> 
> is between the accesses to field warnings_ on lines 1614 and 0865:
> 
> 1610     public void accumulateWarning(SqlWarning e) {
> 1611         if (warnings_ == null) {
> 1612             warnings_ = e;
> 1613         } else {
> 1614             warnings_.setNextException(e);
> 1615         }
> 1616     }
> 
> 0864     public void clearWarningsX() throws SqlException {
> 0865         warnings_ = null;
> 0866         accumulated440ForMessageProcFailure_ = false;
> 0867         accumulated444ForMessageProcFailure_ = false;
> 0868         accumulatedSetReadOnlyWarning_ = false;
> 0869     }
> 
> The latter method is called by clearWarnings(), which is synchronized, 
> but the former method is called by 2 prepareStatement methods along 
> paths which aren't sycnhronized.  In particular, you can follow the "up" 
> links in the above report and see that accumulateWarning(SqlWarning) is 
> called by downgradeResultSetType(int) which is called by 
> prepareStatementX(...) which is called by:
> 
> java.sql.PreparedStatement prepareStatement(String, int)
> java.sql.PreparedStatement prepareStatement(String, String[])
> 
> Hence, if clearWarnings() and one of these prepareStatement methods are 
> executed concurrently in separate threads on the same Connection object, 
> there may be a null pointer exception.  I don't know if such scenarios 
> are possible, but the presence of synchronization in several methods in 
> Connection.java suggests so.
> 
> I would be happy if you could confirm/refute these bugs.  Also, if you 
> are interested in hearing about additional possible synchronization 
> issues in Derby, I can check all of the Derby source code for races -- 
> please let me know.
> 
> Thanks!
> -- Mayur
>