While employed in my application i discovered a scenario by which you will find likely chances to Unque Constraints Breach.I've following options

  1. Catch the exception and throw it to UI
  2. At UI look for the exception and show approrpriate Error Message
  3. This really is different things idea would be to Sign in advance concerning the existance from the given Unique value before beginning the entire operation.

My Real question is what may be the best practice to deal with such situation.Presently we're using combo of Struts2+Spring 3.x+Hibernate 3.x

Thanks ahead of time


Just in case we choose to let database give tha final verdict and we'll handle the exception and propagte that exception to UI and can show Message according to the Exception.That which you suggest ought to be propagate exactly the same exception (org.hibernate.exception.ConstraintViolationException) to UI layer or must we produce a seperate exception class with this since propagating Hibernate exception to UI means polluting the UI classes with Hibernate specific imports along with other things

The easiest method to answer this would be to split it into two ideas.

1) Where's the initial constraint ultimately enforced? Within this situation (out of your question) the reply is the database.

2) Exactly how should we result in the consumer experience better by checking the constraint elsewhere?

Since the database may ultimately decide inside a transaction, there's no helpful check you may make in advance. Even when you check before placing, it's possible (though usually highly unlikely) that another user card inserts that value over time between your check and also the actual place.

So allow the database decide and bubble the mistake look out onto the UI.

Observe that this isn't always true for those constraints. When checking foreign secrets for small tables (like a table people States or Nations or Provinces), the UI offers the user having a selection list, which forces the consumer to choose an permitted value. Within this situation the UI is really enforcing the constraint. Regarded course even for the reason that situation the database must result in the final enforcement, to safeguard against malicious hands-crafted demands to the net layer which are trying deliberately to set up invalid values.

So, for many constraints, yes, allow the UI help. However for unique constraints, the UI really cannot help since the database may be the final authority, and there's no helpful check you may make that you could guarantee it's still true whenever you result in the place.

Is dependent around the UI and when the consumer can perform anything about this, in addition to what else is happening within the system. It's my job to check before trying an place, particularly if there's any kind of transactional logic, or any other card inserts happening after that one. If nothing can compare to that, and also the user can just choose a different number to set up, then catching the exception and exhibiting a mistake message may be all right.