Aha, ThreadLocal. Sounds good, but I still have problems working out how the DAOs get there. OK, I'm possibly being a bit dim here - how does the DAO access the ThreadLocal holding your connection?
Robert Taylor wrote: >Transaction makes the same Connection available to all >DAOs in the same thread by storing it in a ThreadLocal >variable, so I don't have to pass the transaction around. > >robert > > > >>-----Original Message----- >>From: Adam Hardy [mailto:[EMAIL PROTECTED]] >>Sent: Tuesday, June 04, 2002 4:46 PM >>To: Struts Users Mailing List >>Subject: Re: Design Advice - Relational Databases & Java Objects >> >> >>Hi Robert, >>that is more or less what I am aiming to do. I see you don't pass >>connections around - at least not across your business to DAO interface. >>So from your code snippet, I guess your transaction object gets the >>connection and puts it somewhere that the DAOs can find it? Or do you >>pass your transaction object into your DAOs via their constructors? >> >>I am going with the struts connection pool so I'm thinking how I can >>wrap them up without having to repeat lots of error handling in the >>business objects. >> >>Regards >>Adam >> >>Robert Taylor wrote: >> >> >> >>>Adam, when I first started using DAO in my application, >>>I had course grained DAO's that encapsulated transactions. >>>They were responsible for managing the transaction boundries >>>(getting the connection, committing or rolling back, and then >>>releasing the connection). I then found that they were not >>>as reusable and they contained a lot of business logic. I started >>>thinking, this doesn't make sense. To me, it was more intuitive >>>that the DAO should only be responsible for data access and >>>the business logic and transaction management should be a layer >>>above the DAO. So now, my business objects are responsible for >>>managing the transaction (actually they delegate it to another >>>module) and DAOs "join" the transaction in progress. The DAO >>>become more reusable and are decoupled from the mechanism that >>>manages the transaction. So now I have something like the >>>following: >>> >>>ITransaction trans = // get a transaction object >>> >>>try { >>> >>> trans.begin(); >>> >>> dao1.insert(dto); >>> dto2.setForeignKeyId(dto.getIdentity()); >>> dto3.setForeignKeyId(dao1.getIdentity()); >>> >>> dao2.insert(); >>> dao3.insert(); >>> >>> >>>} catch (DatastoreException de) { >>> >>> trans.setRollbackOnly(); >>> throw new BusinessException(de); >>> >>>} finally { >>> >>> trans.end(); >>> >>>} >>> >>> >>>Each DAO joins the transaction (accesses the Connection in the >>> >>> >>same thread) >> >> >>>and uses it to perform the necessary data access operation. A nice side >>>effect >>>is that all the tediousness and complexity involved in managing the >>>transaction is >>>wrapped up in a simple API and not over multiple DAOs. >>> >>>Right now, I use straight JDBC but if I decided to use JDO or another >>>mechanism for transactions, my business client doesn't change. Just like >>>if I change my business logic, my web client (Struts XXXXAction classes) >>>don't have to change. I find this provides more cohesion within layers. >>>That is, the business objects do business stuff by delegating to >>> >>> >>data access >> >> >>>objects and data access objects just access data and tend to deal with >>>tables >>>that are related. >>> >>>This is just one way to do it, as Kevin already mentioned, there >>> >>> >>are other >> >> >>>ways to skin this cat. >>> >>>HTH, >>> >>>robert >>> >>> >>>-- >>>To unsubscribe, e-mail: >>> >>> ><mailto:[EMAIL PROTECTED]> > > >>For additional commands, e-mail: >> >> ><mailto:[EMAIL PROTECTED]> > > >> >> >> >> > > > >-- >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
