You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2007/12/14 11:11:43 UTC
[jira] Created: (DERBY-3275) Mismatch between comments and actual
use of initialSize parameter in CacheFactory and Clock
Mismatch between comments and actual use of initialSize parameter in CacheFactory and Clock
-------------------------------------------------------------------------------------------
Key: DERBY-3275
URL: https://issues.apache.org/jira/browse/DERBY-3275
Project: Derby
Issue Type: Bug
Components: Services
Affects Versions: 10.4.0.0
Reporter: Knut Anders Hatlen
Priority: Minor
The javadoc for org.apache.derby.iapi.services.cache.CacheFactory.newCacheManager() describes the initialSize parameter like this:
@param initialSize The number of initial holder objects that will be created
And org.apache.derby.impl.services.cache.Clock's constructor says the following:
@param initialSize the initial number of cachable object this cache
holds.
@param maximumSize the maximum size of the cache. The cache may grow
from initialSize to maximumSize if the cache policy notices that there
is not enough free buffers availiable. Once the cache hits maximumSize
it will not grow. If the cache is full, an exception will be thrown
However, when Clock is created, it does not populate the cache with "holder objects" or "cacheable [objects]". It only uses the initialSize to specify the initial capacity of the HashMap and the ArrayList that are created.
Either the code should be changed so that it's in line with the comments, or the comments should be changed to match the code. I don't see any compelling reason for changing the code, so I think I would prefer changing the comments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3275) Mismatch between comments and actual
use of initialSize parameter in CacheFactory and Clock
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-3275:
----------------------------------
Urgency: Normal
Triaged for 10.5.2. Set Urgency to Normal.
> Mismatch between comments and actual use of initialSize parameter in CacheFactory and Clock
> -------------------------------------------------------------------------------------------
>
> Key: DERBY-3275
> URL: https://issues.apache.org/jira/browse/DERBY-3275
> Project: Derby
> Issue Type: Bug
> Components: Services
> Affects Versions: 10.4.1.3
> Reporter: Knut Anders Hatlen
> Priority: Minor
>
> The javadoc for org.apache.derby.iapi.services.cache.CacheFactory.newCacheManager() describes the initialSize parameter like this:
> @param initialSize The number of initial holder objects that will be created
> And org.apache.derby.impl.services.cache.Clock's constructor says the following:
> @param initialSize the initial number of cachable object this cache
> holds.
> @param maximumSize the maximum size of the cache. The cache may grow
> from initialSize to maximumSize if the cache policy notices that there
> is not enough free buffers availiable. Once the cache hits maximumSize
> it will not grow. If the cache is full, an exception will be thrown
> However, when Clock is created, it does not populate the cache with "holder objects" or "cacheable [objects]". It only uses the initialSize to specify the initial capacity of the HashMap and the ArrayList that are created.
> Either the code should be changed so that it's in line with the comments, or the comments should be changed to match the code. I don't see any compelling reason for changing the code, so I think I would prefer changing the comments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3275) Mismatch between comments and actual
use of initialSize parameter in CacheFactory and Clock
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-3275:
----------------------------------
Component/s: Newcomer
> Mismatch between comments and actual use of initialSize parameter in CacheFactory and Clock
> -------------------------------------------------------------------------------------------
>
> Key: DERBY-3275
> URL: https://issues.apache.org/jira/browse/DERBY-3275
> Project: Derby
> Issue Type: Bug
> Components: Newcomer, Services
> Affects Versions: 10.4.0.0
> Reporter: Knut Anders Hatlen
> Priority: Minor
>
> The javadoc for org.apache.derby.iapi.services.cache.CacheFactory.newCacheManager() describes the initialSize parameter like this:
> @param initialSize The number of initial holder objects that will be created
> And org.apache.derby.impl.services.cache.Clock's constructor says the following:
> @param initialSize the initial number of cachable object this cache
> holds.
> @param maximumSize the maximum size of the cache. The cache may grow
> from initialSize to maximumSize if the cache policy notices that there
> is not enough free buffers availiable. Once the cache hits maximumSize
> it will not grow. If the cache is full, an exception will be thrown
> However, when Clock is created, it does not populate the cache with "holder objects" or "cacheable [objects]". It only uses the initialSize to specify the initial capacity of the HashMap and the ArrayList that are created.
> Either the code should be changed so that it's in line with the comments, or the comments should be changed to match the code. I don't see any compelling reason for changing the code, so I think I would prefer changing the comments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3275) Mismatch between comments and actual
use of initialSize parameter in CacheFactory and Clock
Posted by "Deepthi Devaki A R (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Deepthi Devaki A R reassigned DERBY-3275:
-----------------------------------------
Assignee: Deepthi Devaki A R
> Mismatch between comments and actual use of initialSize parameter in CacheFactory and Clock
> -------------------------------------------------------------------------------------------
>
> Key: DERBY-3275
> URL: https://issues.apache.org/jira/browse/DERBY-3275
> Project: Derby
> Issue Type: Bug
> Components: Newcomer, Services
> Affects Versions: 10.4.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Deepthi Devaki A R
> Priority: Minor
>
> The javadoc for org.apache.derby.iapi.services.cache.CacheFactory.newCacheManager() describes the initialSize parameter like this:
> @param initialSize The number of initial holder objects that will be created
> And org.apache.derby.impl.services.cache.Clock's constructor says the following:
> @param initialSize the initial number of cachable object this cache
> holds.
> @param maximumSize the maximum size of the cache. The cache may grow
> from initialSize to maximumSize if the cache policy notices that there
> is not enough free buffers availiable. Once the cache hits maximumSize
> it will not grow. If the cache is full, an exception will be thrown
> However, when Clock is created, it does not populate the cache with "holder objects" or "cacheable [objects]". It only uses the initialSize to specify the initial capacity of the HashMap and the ArrayList that are created.
> Either the code should be changed so that it's in line with the comments, or the comments should be changed to match the code. I don't see any compelling reason for changing the code, so I think I would prefer changing the comments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3275) Mismatch between comments and actual
use of initialSize parameter in CacheFactory and Clock
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden reassigned DERBY-3275:
-------------------------------------
Assignee: (was: Deepthi Devaki A R)
Unassigning, due to inactivity. Deepthi, please reassign yourself if you would like to work on this issue.
> Mismatch between comments and actual use of initialSize parameter in CacheFactory and Clock
> -------------------------------------------------------------------------------------------
>
> Key: DERBY-3275
> URL: https://issues.apache.org/jira/browse/DERBY-3275
> Project: Derby
> Issue Type: Bug
> Components: Newcomer, Services
> Affects Versions: 10.4.1.3
> Reporter: Knut Anders Hatlen
> Priority: Minor
>
> The javadoc for org.apache.derby.iapi.services.cache.CacheFactory.newCacheManager() describes the initialSize parameter like this:
> @param initialSize The number of initial holder objects that will be created
> And org.apache.derby.impl.services.cache.Clock's constructor says the following:
> @param initialSize the initial number of cachable object this cache
> holds.
> @param maximumSize the maximum size of the cache. The cache may grow
> from initialSize to maximumSize if the cache policy notices that there
> is not enough free buffers availiable. Once the cache hits maximumSize
> it will not grow. If the cache is full, an exception will be thrown
> However, when Clock is created, it does not populate the cache with "holder objects" or "cacheable [objects]". It only uses the initialSize to specify the initial capacity of the HashMap and the ArrayList that are created.
> Either the code should be changed so that it's in line with the comments, or the comments should be changed to match the code. I don't see any compelling reason for changing the code, so I think I would prefer changing the comments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.