On 4 February 2014 12:19, Gunnar Morling <gunnar(a)hibernate.org> wrote:
2014/2/3 Emmanuel Bernard <emmanuel(a)hibernate.org>
> > On 3 févr. 2014, at 15:21, Sanne Grinovero <sanne(a)hibernate.org> wrote:
> >> On 3 February 2014 13:33, Emmanuel Bernard <emmanuel(a)hibernate.org>
> >> wrote:
> >> Hum, with the fact that this object now points to metadata, I wonder if
> >> we should force EhCache, Map and Infinispan to have their own version
> >> of
> >> EntityKey / RowKey and AssociationKey (or an appropriate externalizer).
> > Ok to consider it, but let's keep an eye on performance requirements:
> > allocating twice the objects which are strictly necessary is probably
> > not going to help.
> > Maybe if these where interfaces, each GridDialect could make his own
> > type ?
> The thing is only the key/value dialects do make use of the keys objects.
> And even in that case, it might not make sense to actually reuse these
> objects. For example if the cache name is the table and only the id columns
> are part of the key.
> Is that edge case worth this complexity (interfaces and splitting the
> metadata)? Maybe with optional methods in the grid dialect? That would still
> make me sad I guess :)
Actually these keys where originally designed to be the keys in
key/value stores and the cost of not reusing them is high, so I'm not
following why you would like to make them not Serializable; indeed
some have some fields which need to be moved out, but there are JIRA's
open for that already as it's an important consideration for storage
size -> memory consumption: OGM-151
I'm not sure I understood what you are suggesting we could do when the
"cache name is the table and only the id columns are part of the key":
to use just the array for the key? Sadly we need to override equals of
the array, so at least one wrapper is needed (unless we find a way to
override comparisons in Infinispan and all others). But a second
wrapper is simply "one too much" because conceptually we don't need
It should be an implementation detail of the specific dialects how
implement the data storage/retrieval contracts, this shouldn't put any
requirements onto these key objects. So if a store choses to persist
directly the keys, it should make sure to do the right thing internally.
For Infinispan we can use a separate strategy via the externalizers (which
as a bonus may result in a better performance than relying on default
serialization). I don't think it's required for the HashMap dialect, leaving
EhcacheDialect as the only problematic case.
Ehcache can handle non-serializable types unless one uses the disk store or
replication functionality. In this case, the recommended way for dealing
with non-serializable types seems to be to write wrapper types with manual
read/write methods. So this would be the only case where we'd have to pay
the costs for doubled allocations as feared by Sanne.
Right each dialect should be able to store with custom strategies for
the specific case, still our SPIs need to "enable" them to be
It's hard to predict what future dialects will need, but having
already a case today which is an example of a limitation, we might
want to take the shortcut to apply a workaround on Ehcache only but it
looks like it would be better to redefine the intention of the
In this case it doesn't even need a code change, as this was already
intended to deal with these same key instances across the whole stack.
So based on that, I'd say we should make these key types non-serializable
and adapt the Infinispan and Ehcache dialects accordingly.
Why was the idea of delegating Key implementation definition to a
dialect specific factory discarded?
> hibernate-dev mailing list