![]() |
Subject: Re: missing synchronization in Connection.java Newsgroups: gmane.comp.apache.db.derby.devel Date: Wednesday 12th October 2005 23:22:57 UTC (over 12 years ago) 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 > |
||