aspose file tools*
The moose likes Object Relational Mapping and the fly likes transaction related exception handling design strategy Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "transaction related exception handling design strategy" Watch "transaction related exception handling design strategy" New topic
Author

transaction related exception handling design strategy

Mohit Sinha
Ranch Hand

Joined: Nov 29, 2004
Posts: 125
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



Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
...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

Joined: Nov 29, 2004
Posts: 125
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
Joe May
Greenhorn

Joined: Sep 28, 2009
Posts: 22
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

Joined: Nov 29, 2004
Posts: 125
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

Joined: Sep 28, 2009
Posts: 22
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

Joined: Sep 28, 2009
Posts: 22
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...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: transaction related exception handling design strategy