[
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:
-------------------------------------------
> Well, honestly I've not considered how well StatementCache was implemented,
> as this wasn't my itch.
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.
> But why create two copies? Why not just return a Vector of PreparedStatements
> directly, then?
That's possible, but I'm not sure it's a good idea to introduce a dependency
from CacheManager/Clock to PreparedStatement. Since this is diagnostic code, I
wouldn't worry too much about copying it twice. Keeping the interface cleaner
is more important in this case, I think.
By the way, if we make values() return a copy, I think it is better if it
returns a collection of Cacheables instead of a collection of CachedItems,
since Cacheable is iapi and CachedItem is impl. (Actually, I think the use in
diag.StatementCache is the only reason why CachedItem is public and not package
private.)
> Let Clock embed a HashMap rather than inherit from Hashtable
> ------------------------------------------------------------
>
> Key: DERBY-2114
> URL: https://issues.apache.org/jira/browse/DERBY-2114
> Project: Derby
> Issue Type: Improvement
> Components: Performance
> Affects Versions: 10.2.1.6
> Reporter: Dyre Tjeldvoll
> Assigned To: Dyre Tjeldvoll
> Priority: Trivial
> Fix For: 10.3.0.0
>
> Attachments: derby-2114.v1.diff, derby-2114.v1.stat
>
>
> Clock currently inherits from Hashtable, but the use of Hashtable is really
> an implementation detail that would benefit from being hidden as private
> member. All access to the hashtable happens inside sychronized blocks so it
> is safe to substitute a HashMap. This change appears to trigger a small
> increase in throughput, as measured by the average TPS number obtained by
> running the select client from DERBY-1961 repeatedly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
