Deepa Remesh (JIRA) wrote:
I have attached a partial patch 'derby-210-patch1.diff' for this problem.
Hello Deepa, I was interested to read your patch because I have been trying to learn how the client code works. After reading your patch, I had a few small questions: 1) I was a bit surprised that there didn't seem to be any obvious Java thread synchronization protecting the CommitAndRollbackListeners and openStatements hash maps. Is there some higher-level synchronization which protects the access to these objects? 2) It seemed a bit unfortunate that you had to touch files like Lob.java and PreparedStatement.java. It seemed like a bit of an encapsulation hole to allow these other classes to directly access the hash maps in the Connection object, rather than going through some sort of convenience method like: connection_.addCommandAndRollbackListener(this); 3) I thought it was interesting that Connection.java favors the style: final java.util.WeakHashMap openStatements_ = new java.util.WeakHashMap(); as opposed to the more common (I think) style of: import java.util.WeakHashMap; final WeakHashMap openStatements_ = new WeakHashMap(); Is there a reason that the client code seems to favor the use of explicitly qualified class names rather than using import statements? Anyway, thanks very much for posting your patch for review. I find it very educational to read the patches and try to understand how they work. thanks, bryan
