title: DAO pattern - where do transactions fit in?
body: <p>So I've got this generic DAO thing going on and at face value it appears to be ok.  It's basically modeled after the CaveatEmptor sample application from the Hibernate guys.  </p>
  
  <p>On top of that I have a business layer...the guts of the application.  It's completely unaware of any specific DAO implementation.</p>
  
  <p>Everything up to this point seems fine, until I start thinking about transactions.  If transactions are left to the client to implement, then how in the world do I maintain the nice separation I've got going on between my layers?  That is, I'm using Hibernate at the moment, and I don't really feel much like adding hibernate-specific transactions to my business layer code.</p>
  
  <p>I could create a simple transaction interface with begin, commit, and rollback methods and pass an implementation to my business layer...but...I'm not sure...</p>
  
  <p><strong>So here is the challenge: can you recommend a way for me to do this without using the word Spring (or EJB, or any other additional framework)?</strong></p>