Thanks for this contribution.

Consider, though, the problem where you have a uniqueness constraint on 
a colummn in your database.  When this is violated, the database will 
throw an exception as  part of the flush. Because of the exception, your 
postFlush interceptor code will not get called.

The good news is that the transaction fails and the database is 
protected.  The bad news is that it is pretty much impossible to convert 
the exception into a meaningful message for the end user.  In fact the 
exact exception that is thrown depends on the appServer and/or database 
being used.  It will not provide enough information to let you form a 
reasonable message like "a User is already defined with this user-id, 
please choose another".

From the point of view of providing a nice UI, it would be better to use 
the database as a last line of defense and catch the error in java code.  
But this means doing a Query, which has all the problems you mention.

One solution is to use the Validateable interface but solve the session 
limitation problem by opening a new session that exists only for the 
validate() call.  Any o