Are the JPA callback methods useful?
Join the DZone community and get the full member experience.
Join For FreeDefinitely no. The section 3.5 of JPA specification states:
“In
general, the lifecycle method of a portable application should not
invoke EntityManager or Query operations, access other entity instances,
or modify relationships within the same persistence context. A
lifecycle callback method may modify the non-relationship state of the
entity on which it is invoked.”
Surely
these restrictions has a good technical reason behind them, but from a
business application developer perspective they mean that JPA callback
methods are practically useless.
For example, these scenarios are typical:
- In order to remove some entity we need to verify if some data exists, and we want do it using a JPA query.
- When an entity is saved, some other entities must be automatically created and saved, and we want to use the JPA EntityManager to do so.
Unfortunately, it’s difficult to solve such cases using the standard annotations: @PrePersist, @PostPersist, @PreRemove, @PostRemove, @PreUpdate, @PostUpdate or @PostLoad.
- In order to remove some entity we need to verify if some data exists, and we want do it using a JPA query.
- When an entity is saved, some other entities must be automatically created and saved, and we want to use the JPA EntityManager to do so.
Unfortunately, it’s difficult to solve such cases using the standard annotations: @PrePersist, @PostPersist, @PreRemove, @PostRemove, @PreUpdate, @PostUpdate or @PostLoad.
What can we do?
We have several options such as:- Using JDBC from the callback methods: Horror!
- Create a new EntityManager in the callback method: This works sometimes, but you can have problems with isolation levels. Moreover, you lose the transactional behavior.
- Put the on-save or on-remove logic in the controller layer, that is in the actions: Of course, this works just fine, but if you access to the entities from other actions, from a batch process, or from a web service, the on-logic or on-remove will not be executed.
Obviously, these options are dirty and unnatural, and even even worse, they mean more work for us.
Create your own callback annotations
In OpenXava,
we have opted for the simplest solution for the poor application
developer, just creating some new callback annotations that allow to use
JPA inside them. OpenXava 4.0.1 includes the next new annotations: @PreCreate, @PostCreate and @PreDelete.
For example, if we need to create a customer and assign it to an invoice when the customer is not specified, you can write:
@PreCreate
public void onPreCreate() {
// Automatically create a new customer
if (getCustomer() == null) {
Customer cust = new Customer();
cust.setName(getName());
cust.setAddress(getAddress());
cust = XPersistence.getManager().merge(cust); // Here we use the EntityManager
setCustomer(cust); // and here we change a relationship
}
}
If
you want to enjoy these annotations just use OpenXava for developing
your application. Although if you are not still ready for rapid
development, you can create these annotations yourself easily, just use
the decorator pattern over the EntityManager or use AOP to refine the behavior of persist() and remove() methods.
Learn more about these annotations
Opinions expressed by DZone contributors are their own.
Comments