Hibernate: Event Listener or Interceptor, what are the pros/cons in practice?

Question

I will be implementing a feature to update an id in a table after Hibernate does my deletes. But I want to get some feedback on which approach is better. Also the table I am updating the value in, Hibernate doesn't know about it so I would have to do a straight jdbc update -- is that even possible.

Answer 1

As far as using listener / interceptor goes, I'd go with listener - it's more flexible in terms of events that can be listened to. Interceptor's primary purpose is to inspect / alter object properties prior to some event (e.g. deletion); whereas listener can be configured to listen to "PostDelete" event or many others.

However, if said table is not mapped why do you need either? You can instead update it directly in your code after you've called delete() (or after you've called flush() if there's a foreign key involved).

You can also do that in a trigger (possibly; depending on whether necessary information is available in the database, of course).

Answer 2

It seems that many prefer Listeners - they offer a broader list of events and are more flexible, but there are things that Interceptors offer and Listeners do not.

For example, if you want to modify the entity before saving it to the database, an Interceptor should be used.

Answer 3

As i know, Interceptors are the old implementation of the hibernate team and the listeners are the new flexible version of interceptors. Imho its easier to use hibernate listener as Interceptors.