The DAOs have a method called getConnection(). Inside getConnection() they call Transaction.getTransactionContext(). TransactionContext contains the Connection and other information about the Transaction. Although, TransactionContext is held within the static ThreadLocal variable, it is garanteed to be unique for each thread, thus providing the same Connection for all DAOs in the same thread that join the transaction.
HTH, robert > -----Original Message----- > From: Adam Hardy [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 05, 2002 2:33 AM > To: Struts Users Mailing List > Subject: Re: Design Advice - Relational Databases & Java Objects > > > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
