Menu
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 composed 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!
886
Hazelcast smoothly integrates with Hibernate 3 and Hibernate 4, providing distributed caching support based on Hazelcast IMap technology. Features like scalability, in-memory backups, and automatic eviction are fundamentals of the Hazelcast architecture. Hazelcast brings those features to the Hibernate world.
In eager loading strategy, if we load the User data, it will also load up all orders associated with it and will store it in a memory. But when we enable lazy loading, if we pull up a UserLazy, OrderDetail data won't be initialized and loaded into a memory until we make an explicit call to it.
Eager Loading is a design pattern in which data initialization occurs on the spot. Lazy Loading is a design pattern which is used to defer initialization of an object as long as it's possible.
Lazy Loading vs. Eager Loading. While lazy loading delays the initialization of a resource, eager loading initializes or loads a resource as soon as the code is executed. Eager loading also involves pre-loading related entities referenced by a resource.
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...
142
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
