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

[Gunnar Morling]

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 :)
>

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.

So based on that, I'd say we should make these key types non-serializable
and adapt the Infinispan and Ehcache dialects accordingly.

--Gunnar


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