Announcement Announcement Module
No announcement yet.
hibernate template Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • hibernate template

    There are some DataAccessExceptions that I would like to catch ... such as DataIntegrityViolation (really just the duplicate key exception) . All of my transactions start and end at the service level as most of the examples in the spring documentation demonstrate. Could someone please clarify if I can catch these exceptions in the service layer ? I was under the impression that these exceptions would only be available to the caller of the serivce layer. If I wanted to make these available to the service layer then I would have to set eager flushing on the hibernate template. Everytime I try and catch a data integrity violation it is only available to the caller of the service layer. If I set eager flushing in the template it seems to work ... I can then catch the exception inside the service method .. as oppose to the caller of the service method. I would like to catch these exceptions in the service layer and rethrow them as some service level exception .. because these errors are recoverable.

    Thanks again

  • #2
    Exceptions for Control flow = bad

    you can check for duplicate before you insert (with business logic), so why use exceptions for control flow. this is a poor practice.



    • #3
      Not sure if it is considered "poor practice". If I do it with business logic then you would have to code that for every save and update method. In the event u made more of the columns unique in the database then you would have to also modify your select statement or hql to include these. With exceptions .. and custom exception translator your can throw exceptions for these cases .. instead of coding it for each save or update.


      • #4
        Not to mention the performance implication of doing a select before insert .. for the most part the duplicate code should not occur in every case ... with your select before insert approach you will always incure the select overhead. Depending on the size of the database table and the frequency of transactions this approach becomes less viable.


        • #5
          Personally, I do like to check things with code specifically. A lot of the time, catching a DataIntegrityViolationException is not granular enough anyways. Consider a service method where you want to throw a different error on duplicate username or email. If you just catch a DataIntegrityViolationException, then you have no way of telling which duplicate column caused the error.

          In any case, w/regards to your original question, yes, with Hibernate, you will only get a flush on the commit of thr transaction (which will happen on exiting the service layer that is wrapped by the transaction, to which the Hibernate Session is bound), and also when Hibernate itself decides it needs to flush, as when a query is issued. Instead of setting eager flushing on the template, which will kill your peformance, you could force a flush yourself, although you would probably want to wrap it so it is not Hibernate specific as far as the service layer code is concerned.


          • #6

            well it all really depends on how you build your key?
            is it a user defined field?
            if so this should be checked before inserted. (like duplicate username)
            its a business case where you'd send a response back to the user to try again.