• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

transaction related exception handling design strategy

 
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
All,

I am currently working on core Java hibernate 3 tier application (controller -> service ->dao ->orm)
All transactions incept at the service layer. The controller coordinates the entire flow of events (i.e. invoking the right service layer components) for handling an incoming request.
We are not using any checked exceptions. All exceptions within the app are runtime exceptions. And there is only one catch block at the controller layer for trapping all runtime exceptions.

In this catch block at the controller layer we have a dedicated exception handler utility which logs/persists the exception details. My question is related to Hibernate transactions and exception handling.
Say a particular transaction commit fails or say there is a failure even before commit. This exception propagates back to the controller layer wherein we have the runtime exception handler. Here the first thing I do is rollback the transaction and then proceed with logging of the exception details.

The reason I am not creating individual try/catch blocks is some events are crucial and in the event of failure related to these we need to halt the execution and provide appropriate failure details.
For other non-crucial errors we suppress the exceptions in a catch block.

I would like to know your thoughts on this approach of using runtime exceptions throughout and having a single catch for handling all runtime exceptions.

Thanks - Mohit



 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

...3 tier application (controller -> service ->dao ->orm)



To describe this in a more common fashion to increase understandability, it would be:

Presentation - Business - Integration

There are the names of the three-tier J2EE model.

Your "controller" is a part of the Presentation tier along with (optional) GUI components or a command-line interface.

Your "service" is part of the Business tier.

Your "dao" is part of the Integration tier. And if you are using a ORM implementation, then this is part of your DAO implementation and is also a part of the Integration tier.
 
Mohit Sinha
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
James,Thanks for clarifying on that part of the post.

But my question was more towards the centralized exception handling approach and resorting to using java runtime exceptions only.
Does it make sense to avoid all exception handling in the lower layers (dao [integration], services [business]) and have single handler at the controller [presentation] layer.

The reason I brought in the Hibernate ORM specific question is we have a Hibernate rollback operation within the centralized exception handler.

Regards,
Mohit
 
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Therz one thing i do not understand here... you say transactions start at service layer... but you're rolling back at the controller? Not sure how you define your transactions....
 
Mohit Sinha
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
transactions start at the service layer.

We have a generic exception handler class which has the responsibility of dealing with runtime exceptions (logging, persisting to the database).
This exceptionHandler gets invoked only from one place (i.e. controller) in the event of any runtime exception so it does not belong to the controller layer as such.
 
Joe May
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hmmm.. then i assume that you keep the session alive in the controller which i dont think is a great idea.... anyway.. i am not a expert here..let some one else reply to this

-Mec
 
Joe May
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
another possible flaw i see in this is tat if your service code gets called outside a web context.. say from a web service.. then your transactions will fail...
 
reply
    Bookmark Topic Watch Topic
  • New Topic