Hibernate lazy loading and Hazelcast

we are using Hazelcast as Hibernate 2nd level cache now for a while but are recognizing long delays in storing and reading data when using more than one node.

We make intensive use of compo开发者_如何转开发sed objects and @OneToMany relations, and to increase performance we decided to load these composed objects or collections via Hibernate lazy loading. We also implemented DataSerializable to speed up Hazelcast serialization, as it is stated in the Hazelcast documentation. But logging the use of the writeData/readData methods showed us that they were not used actually!

It is unclear for us now, if the Hibernate Proxy (which is used via lazy loading) prevents the use of DataSerializable methods (because the proxy itself might (?) not implement the interface) and - even more important - if Hazelcast supports lazy loading at all - and how!

---

Hazelcast's DataSerializable has no use with Hibernate L2 cache, because stored objects in Hazalcast cluster are not your entity objects. Hibernate uses its own data (say, serialization) format in L2, converts your entities and their relations and collections to its own format and gives its own objects (implementing java.io.Serializable) to Hazelcast. Hazelcast serializes those using standard java serialization and distributes across cluster.

If your classes have complex and deep object graph (intensive use of composed objects and 1xn or similar relations), this dual-serialization issue causes long delays.

Hazelcast has nothing to do with Hibernate's lazy-loading. Hibernate already stores entities and their relations and collection mappings separately. So all those can be loaded from Hazelcast one-by-one. But in your use-case, if most of lazy-loadable relations are always loaded, then that will cause multiple remote Hazelcast calls instead of one. So you should think carefully where to use lazy-loading.

Another trick is to use/enable Hazelcast near-cache, if your app mostly read-only. (Btw if it is not, then using L2 cache maybe not suitable for you.) That way you will save lots of remote calls and frequently needed data will be cached locally. Near cache supports all Hazelcast map properties such as TTL, eviction, max-size etc.

Hazelcast Near-Cache documentation...