you have a @PrePersist and a @PreUpdate envent as per the EJB3 spec.
But I would recommend you to use DB triggers anyway if you don't care abour DB portability.
You can do that in hibernate hbm file through auxiliary database objects
Emmanuel, you don´t recommend Hibernate PreUpdateEventListener. Why? I've have the same scenario and choose this technique. Did I take the wrong technique?
Personally my thought was that PreUpdateEventListener would be the cleaner way to implement the feature. The Trigger would be written in the same language as your application. Because its ejb, you already depend heavily on the ejb container, so java is already must have.
The problem might be the performance issue.
Did you recognize bottlenecks in your applications history facility? (More db roundtrips in comparison to the db internal trigger)
With all your logik inside your ejb layer, another application working directly with your tables would be able to bypass the history mechanism. So the db trigger would ensure that all updated entries are stored inside the history table.
So i think both possibilities got their (dis)advantages. The right technique depends on your usage or im wrong?
envent listener are fine, this is not EJB3 standard, that's all.