Transaction lives in the VM and therefore the DAOs have access to its static methods which are used to get the Connection in the current thread via the methods described below.
If you have any further questions about implementation, please email me directly, [EMAIL PROTECTED], so we can cut down on topics not directly related to Struts. robert --- Adam Hardy <[EMAIL PROTECTED]> wrote: > ... (still being dim) ... but how do the DAOs see > the Transaction object? > > Robert Taylor wrote: > > >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 > >>>> > >>>> > >>>> > === message truncated === __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
