Implementing Audit Trail- Spring AOP vs.Hibernate Interceptor vs DB Trigger Implementing Audit Trail- Spring AOP vs.Hibernate Interceptor vs DB Trigger database database

Implementing Audit Trail- Spring AOP vs.Hibernate Interceptor vs DB Trigger


I only can talk about Triggers and NHibernate, because I don't know enought abou tSpring AOP.

It depends on, as always, what is most important for you.

DB triggers

  • are fast
  • are always called, even from native SQL, Scripts, external apps.
  • write data in the DB of which NH doesn't know about. It will be missing in the current session. (Which could lead to unexpected results)
  • do usually not know anything about your session (say: login name).

NHibernate interceptors / events

  • are not DBMS specific.
  • allow you easy access to you business information, like the user session, client machine name, certain calculations or interpretations, localization, etc.
  • allow you declarative configuration, like attributes on the entity, which define if the entity needs to be logged and how.
  • allow you turning off logging, this could be important for upgrades, imports, special actions that are not triggered by the user.
  • allow you an entity view to the business model. You are probably closer to the users point of view.


I understand this is not 100% related to the question but it does add value with new options.

There are two more ways you can audit what’s going on.

Reading transaction log: If database is in full recovery mode then all details about INSERT, UPDATE, DELETE and DDL statements are logged into transaction log.

Problem is that it’s very complex to read because it’s not natively supported and that you’ll need a third party transaction log reader such as ApexSQL Log or SQL Log Rescue (the latter one is free but only supports sql 2000).

Advantage of this method is that you literally don’t have to make any changes except to put your database in full recovery mode.

SQL Server traces: Traces will capture everything in trace files including select statements which also may be needed for some compliance scenarios. The downside is that traces are text files that need to be parsed and organized.


I can't think of any good reason for not using database triggers to audit changes to the database. Inserts, updates and deletes can potentially hit the database from various sources - triggers will catch all these; Hibernate etc. will not.