[hibernate-dev] [OGM] When is AssociationKey serialized?

[Sanne Grinovero]

On 4 February 2014 12:19, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2014/2/3 Emmanuel Bernard <emmanuel at hibernate.org>
>>
>>
>>
>> > On 3 févr. 2014, at 15:21, Sanne Grinovero <sanne at hibernate.org> wrote:
>> >
>> >> On 3 February 2014 13:33, Emmanuel Bernard <emmanuel at 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.


> It should be an implementation detail of the specific dialects how they
> 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
efficient.
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
existing SPI.
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?

Sanne

>
> --Gunnar
>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>