[
https://issues.jboss.org/browse/ISPN-1078?page=com.atlassian.jira.plugin....
]
Trustin Lee updated ISPN-1078:
------------------------------
Description:
{{LockSupportCacheStore}} uses {{String}} as its locking key. It is OK as long as the
locking key can be represented as a {{String}} without much conversion cost. However, it
the extending {{CacheStore}} implementation uses other type such as {{byte[]}} as its
primary key type, it will result in unnecessary conversion from byte[] to String to
achieve fine grained locking. I found a similar problem in
{{[BucketBasedCacheStore|http://j.mp/m9tLwU]}} - it's converting an integer into a
{{String}} unnecessarily.
Therefore, I propose to generify {{LockSupportCacheStore}}:
{code}
/**
* @param L the type of the locking key
*/
public abstract class LockSupportCacheStore<L> ... {
...
protected abstract String getLockFromKey(L key) throws CacheLoaderException;
...
}
{code}
Then {{BucketBasedCacheStore}} and the new {{CacheStore}} implementation I'm writing
for ISPN-701 will be more efficient.
Mircea, could you confirm if my idea doesn't break anything? Because it's not a
backward compatible change, I'd like to get this done before cutting the first
candidate release.
was:
{{LockSupportCacheStore}} uses {{String}} as its locking key. It is OK as long as the
locking key can be represented as a {{String}} without much conversion cost. However, it
the extending {{CacheStore}} implementation uses other type such as {{byte[]}} as its
primary key type, it will result in unnecessary conversion from byte[] to String to
achieve fine grained locking. I found a similar problem in
{{[BucketBasedStore|http://j.mp/m9tLwU]}} - it's converting an integer into a
{{String}} unnecessarily.
Therefore, I propose to generify {{LockSupportCacheStore}}:
{code}
/**
* @param L the type of the locking key
*/
public abstract class LockSupportCacheStore<L> ... {
...
protected abstract String getLockFromKey(L key) throws CacheLoaderException;
...
}
{code}
Then {{BucketBasedCacheStore}} and the new {{CacheStore}} implementation I'm writing
for ISPN-701 will be more efficient.
Mircea, could you confirm if my idea doesn't break anything? Because it's not a
backward compatible change, I'd like to get this done before cutting the first
candidate release.
Allow a non-String object as a locking key in LockSupportCacheStore
-------------------------------------------------------------------
Key: ISPN-1078
URL:
https://issues.jboss.org/browse/ISPN-1078
Project: Infinispan
Issue Type: Enhancement
Components: Loaders and Stores
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 5.0.0.CR1, 5.0.0.FINAL
{{LockSupportCacheStore}} uses {{String}} as its locking key. It is OK as long as the
locking key can be represented as a {{String}} without much conversion cost. However, it
the extending {{CacheStore}} implementation uses other type such as {{byte[]}} as its
primary key type, it will result in unnecessary conversion from byte[] to String to
achieve fine grained locking. I found a similar problem in
{{[BucketBasedCacheStore|http://j.mp/m9tLwU]}} - it's converting an integer into a
{{String}} unnecessarily.
Therefore, I propose to generify {{LockSupportCacheStore}}:
{code}
/**
* @param L the type of the locking key
*/
public abstract class LockSupportCacheStore<L> ... {
...
protected abstract String getLockFromKey(L key) throws CacheLoaderException;
...
}
{code}
Then {{BucketBasedCacheStore}} and the new {{CacheStore}} implementation I'm writing
for ISPN-701 will be more efficient.
Mircea, could you confirm if my idea doesn't break anything? Because it's not a
backward compatible change, I'd like to get this done before cutting the first
candidate release.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira