And will conditional operations on byte[] work as well within this fix? I have just
noticed that in library mode I can't use remove with byte[] value (should I file a
feature request JIRA for that?)
Radim
----- Original Message -----
| From: "Tristan Tarrant" <ttarrant(a)redhat.com>
| To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
| Sent: Monday, March 18, 2013 3:39:05 PM
| Subject: Re: [infinispan-dev] Bye bye wrappers, ComparingConcurrentHashMapv8 is here
(ISPN-2281)
|
| On 03/18/2013 01:21 PM, Galder Zamarreño wrote:
| > Hi all,
| >
| > A heads up on what is going on with
| >
https://issues.jboss.org/browse/ISPN-2281
| >
| > While discussing this, Tristan and I came to the conclusion that we
| > could avoid the need to create some wrappers required to fulfill
| > requirements in this JIRA, and as a side effect, reduce the memory
| > consumption of Infinispan servers, if we could have internal data
| > containers based on concurrent hash maps that took a custom
| > function for equals/hashCode…etc. By doing that, you could
| > effectively have **byte[] keys and values for maps**.
| >
| > By doing that, you avoid creating wrappers (yippee!) for keys (bye
| > bye ByteArrayKey), and combined with a better way to pass metadata
| > into Infinispan Caches (i.e. version) that is stored within the
| > internal cache entries, you avoid wrapper values too! (bye bye
| > CacheValue).
| >
| Pushing this even further would be to keep data and metadata separate
| in
| the store representation too as we currently write/read marshalled
| InternalCacheEntries to the stores. Probably this will have to wait
| for
| 6.0 when we overhaul the stores.
|
| Tristan
|
| _______________________________________________
| infinispan-dev mailing list
| infinispan-dev(a)lists.jboss.org
|
https://lists.jboss.org/mailman/listinfo/infinispan-dev
|