Announcement Announcement Module
No announcement yet.
Question regarding wrapping service layer methods with transaction support Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Question regarding wrapping service layer methods with transaction support

    Hi Folks,

    I've gotten declarative transaction management down with regular JDBC datasources and hibernate datasources. As I'm continuing to implement my architecture of service -> dao layers, I'm finding it kind of awkward that with my service methods being the ones proxied for transaction management, rollback only occurs when an exception is thrown in those methods. What this means then is that a DAO exception needs to propagate up the call stack and get thrown by my service layer where Spring grabs it and performs the rollback. The obvious solution to this I guess is to wrap the DAO methods with transaction management, but I've read everywhere that this is not a good idea. So, this being sort of an open-ended architectural question, why is it bad to wrap DAO methods with transactions. I would find it ideal if transaction management would happen when a DAO failed, not necessarilly its calling service layer. Any words of wisdom on this subject would greatly be appreciated. Thanks.

  • #2
    Where to Demarcate Transactions

    Before we get into the different demarcation strategies, it is important to consider where we should apply transactions in our applications. We recommend applying transactions at the business layer. This allows the business layer to catch any exceptions that caused a rollback and issue the appropriate business-level application exceptions.

    We don't want to apply them at the data access level because that would limit the opportunity to reuse data access code with varying transaction requirements. Data access code should not delimit transaction boundaries because it doesn't implement business logic, and atomicity is a business-level concept. Let's say we apply a transaction on a data access method that updates the balance of an account. This would prevent us from reusing this method in a task that transferred data between two accounts. If the subtraction from the first account was already committed, then we could not roll back all changes in the case of the addition to the second account failing. We should instead apply the transaction at the higher business operation level. This would in our case be the "deposit," "withdraw," and "transfer" business method.

    Introducing Spring's Transaction Abstraction
    Professional Java Development with the Spring Framework
    byRod Johnsonet et al.
    John Wiley & Sons 2005 (672 pages)
    I do agree with the above and always demarcate my stuff on business layer.
    Transactions as well as security are business level concerns.
    Actually I did it before I was introduced to Spring. That's why I love Spring to begin with. It's so much in tune with my line of thinking


    • #3
      Thanks for the reply Arno,

      So essentially my approach should be to wrap the dao calls in my method with try/catch blocks, then throw more business-specific exceptions within those catches. It is the throwing of those business exceptions that trigger the transaction rollback? This makes sense! Currently my business layer is declaring in its methods DataAccessExceptions, I didn't think that was ever an appropriate thing to do, hence this post. Thanks again.


      • #4
        I might be completely missing your problem here - did you try declaring in your transaction attributes so that any exception would cause a rollback? By default only checked exceptions would do that.