db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2114) Let Clock embed a HashMap rather than inherit from Hashtable
Date Thu, 15 Mar 2007 11:23:09 GMT

    [ 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

> But why create two copies? Why not just return a Vector of PreparedStatements directly,
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:
>            Reporter: Dyre Tjeldvoll
>         Assigned To: Dyre Tjeldvoll
>            Priority: Trivial
>             Fix For:
>         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.

View raw message