[infinispan-issues] [JBoss JIRA] Updated: (ISPN-1078) Allow a non-String object as a locking key in LockSupportCacheStore

[ 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. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira