StackOverflow is a gold mine! Check out this question I bumped into this morning. Basically, our Hibernate user wants a resilient
CharacterType which works with
NULL or empty values. To make it even more interesting, we are going to make it work even if the underlying database column contains more than one character.
Continue reading “How to implement a custom basic type using Hibernate UserType”
When fetching an entity, all attributes are going to be loaded as well. This is because every entity attribute is implicitly marked with the
@Basic annotation whose default fetch policy is
However, the attribute fetch strategy can be set to
FetchType.LAZY, in which case the entity attribute is loaded with a secondary select statement upon being accessed for the first time.
@Basic(fetch = FetchType.LAZY)
This configuration alone is not sufficient because Hibernate requires bytecode instrumentation to intercept the attribute access request and issue the secondary select statement on demand.
Continue reading “The best way to lazy load entity attributes using JPA and Hibernate”
LazyInitializationException is undoubtedly one of the most common exceptions you can get when using Hibernate. This article is going to summarize the best and the worst ways of handling lazy associations.
Continue reading “The best way to handle the LazyInitializationException”
I’ve already written about the Open Session in View Anti-Pattern, so now it’s time to add another Hibernate fetching bad practices. Although the
hibernate.enable_lazy_load_no_trans configuration property is a lesser known setting, it’s good to know why you shouldn’t employ it in your data access layer code.
Continue reading “The hibernate.enable_lazy_load_no_trans Anti-Pattern”
StackOverflow and the Hibernate forum are gold mines. Yesterday, I bumped on the following question on our forum:
Usually, the rationale behind clustering objects together is to form a transactional boundary inside which business invariants are protected. I’ve noticed that with the OPTIMISTIC locking mode changes to a child entity will not cause a version increment on the root. This behavior makes it quite useless to cluster objects together in the first place.
Is there a way to configure Hibernate so that any changes to an object cluster will cause the root object’s version to increment? I’ve read about OPTIMISTIC_FORCE_INCREMENT but I think this does increment the version regardless of if entities were changed or not. Since reads shouldn’t be conflicting with other reads in most scenarios, this doesn’t seem so useful either.
I could always increment the version inside every mutating behavior of the root, but that is quite error-prone. I’ve also thought of perhaps using AOP to do this, but before looking into it, I wanted to know if there were any easy way to do that. If there were a way to check if an object graph is dirty, then it would make it quite easy to implement as well.
What a brilliant question! This post is going to demonstrate how easy you can implement such a requirement when using Hibernate.
Continue reading “How to increment the parent entity version whenever a child entity gets modified with JPA and Hibernate”