"Knut Anders Hatlen (JIRA)" <[EMAIL PROTECTED]> writes: > [ > https://issues.apache.org/jira/browse/DERBY-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481114 > ] > > Knut Anders Hatlen commented on DERBY-2114: > ------------------------------------------- > > This is not so much about the implementation of StatementCache. My > worry is that by requiring the callers of CacheManager.values() to > synchronize on the CacheManager and hold the synchronization while > traversing the returned collection, it will be harder to replace > Clock with another implementation of CacheManager later because the > interface implicitly dictates how the internal synchronization must > be implemented. If someone wants to rewrite the cache manager, say, > to allow threads to enter it concurrently, she couldn't just > implement the interface and plug in the new implementation since the > interface required that there was a global synchronization point.
I accept this argument, but there's still nothing preventing any CacheManager/Clock client from synchronizing on it, so whoever takes on that rewrite will still have to carefully check that this doesn't happen. -- dt
