Javier has posted 48 posts at DZone. View Full User Profile

Are the JPA callback methods useful?

01.12.2011
| 6148 views |
  • submit to reddit

Definitely 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

0
Your rating: None
Published at DZone with permission of its author, Javier Paniza.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

John J. Franey replied on Thu, 2011/01/13 - 7:39am

Doesn't this approach risk implementing business level logic into the model?

The restriction that an order must have a customer can be specified with bean validation annotation (@NotNull) on the order's customer field. Also, the database can define a not-null constraint on the column. Both of these would enforce a data model integrity rule to the client code of the model. In testing, the programmer would get an exception of the constraint failure. DRY could be resolved by implementing a shared library of business level logic, like, 'create order' for example.

What is the trade-off between this article's technique and a library of business logic? How can I prevent business logic from leaking into the model?

Andy Gibson replied on Thu, 2011/01/13 - 11:15am

>Definitely no.

 More like definitely maybe,  there is still plenty of things that can be done in the call backs such as auditing or triggering CDI events or JMS messages. Anything meatier than that really needs to be insome kind of business logic layer rather than tying it in with model callbacks.

 Cheers,

 Andy

Javier Paniza replied on Thu, 2011/01/13 - 12:27pm

Hi John,

The restriction that an order must have a customer can be specified with bean validation annotation (@NotNull) on the order's customer field

Of course. But in this case we want to create the customer if he does not exist.

implementing a shared library of business level logic

That goes against my basic principles. I like to write the entire application using only domain classes.

Hi Andy,

More like definitely maybe,  there is still plenty of things that can be done in the call backs such as auditing or triggering CDI events or JMS messages

You're right. I exaggerated. However, the programmers I know rarely do such things, and very often need to read and write data in the database.

that really needs to be insome kind of business logic layer rather than tying it in with model callbacks

For me the JPA entities are the business model layer, and the only layer you have to write to get an OpenXava application running.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.