db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dyre Tjeldvoll (JIRA)" <j...@apache.org>
Subject [jira] Reopened: (DERBY-2114) Let Clock embed a HashMap rather than inherit from Hashtable
Date Wed, 14 Mar 2007 12:18:09 GMT

     [ https://issues.apache.org/jira/browse/DERBY-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Dyre Tjeldvoll reopened DERBY-2114:

Reopening this issue since I now have an idea about how to solve the VTI problem. 

The real problem was not really related to VTIs, but to the implementation of StatementCache.
Its constructor looks up the LanguageConnectionContext's statementCache which is of type CacheManager,
and implemented by Clock. Since the CacheManager interface doesn't support iteration over
the elements of the cache, a hack has been introduced here. The knowledge that a CacheManager
really is a Clock AND that Clock extends Hashtable is used to cast lcc.statementCache to Hashtable.
This Hashtable is then used to do the iteration. However, this hack defeats the purpose of
having the CacheManager interface since it creates a solid unwanted dependency between the
implementation of StatementCache and the implementation of Clock. 

If iteration is to be allowed it is better to extend the CacheManager interface with the necessary
methods (They can't simply be added to Clock, since StatementCache isn't allowed to downcast
to Clock  which isn't public in its package.) 

> 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:
> 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