本文介绍了Hibernate的二级缓存中自定义用户类型的内部表示的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

Hibernate将实体以脱水形式存储在第二级缓存中。这对我来说很好,直到自定义用户类型进入场景,特别是库,我使用它来映射Joda时间类型。



持久性可以正常工作,但,Hibernate会将一个raw(序列化)引用放到 LocalDate 实例放入其第二级缓存中,这会导致一些问题,因为每个 LocalDate 实例都会保留大量内部数据结构的引用,这些引用不应该在缓存中显示。

有没有办法挂钩到Hibernate(de-)水合策略中,以获得对最终哪些数据最终将存储在其二级缓存中的细粒度控制?

解决方案

Jadira的UserType库使用 org.hibernate.usertype.UserType 来实现它的自定义类型。 UserType 实例在放入第二级缓存时简单地序列化,这对于Joda时间实例来说是理想选择。



这个问题可以通过使用 org.hibernate.usertype.CompositeUserType 来解决,而不是在实现自定义类型时,它可以让你完全控制实体应该如何(去)水合当把它放入(或从缓存中取出)的时候。



我向Jadira提交了一个功能请求,但现在我只是通过实现我自己的自定义类型。


Hibernate stores entities in a dehydrated form in its 2nd level cache. This works fine for me until custom user types enter the scene, particulary Jadira's UserType library, which I use to map Joda time types.

Persistence works fine out of the box, but I've discovered that Hibernate will put a "raw" (serialized) reference to a LocalDate instance into its 2nd level cache, which causes some problems, because each LocalDate instance keeps tons of references to internal datastructures, which should not turn up in the cache.

Is there a way to hook into Hibernate's (de-)hydration strategy to get fine grain control over which data will eventually be stored in it's 2nd level cache?

解决方案

Jadira's UserType library uses org.hibernate.usertype.UserType to implement its custom types. UserType instances are simply serialized when put into the 2nd level cache, which is a less then ideal choice for Joda time instances.

The Problem could be solved by using org.hibernate.usertype.CompositeUserType instead when implementing custom types, which gives you full control how entities should be (de-)hydrated when put into (or taken out of) the cache.

I filed a feature request with Jadira, but for now I'll just move forward by implementing my own custom types.

这篇关于Hibernate的二级缓存中自定义用户类型的内部表示的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

10-19 19:08