Have you looked at using something like the iBATIS DAO? I think it could save you alot of pain.
One thing to watch out for is thread safety - putting a connection on an instance (especially a shared instance) is pretty risky, especially when you start thinking about transactions and the like...that kind of thing is really better handled at the thread level (which is what iBATIS does). Larry On 8/23/05, Paul Benedict <[EMAIL PROTECTED]> wrote: > Guys, > > This is off-topic but I need your help. There are some > good programmers here and I would like to receive some > advice back. I am sure there's a simple answer to it. > > My Struts app is a multitier app (Web -> Business -> > DAO) and it uses Jakarta Commons DbUtils for the DAO > layer. My DAO methods are the typical get > connection,execute,close connection pattern. Well, > suddenly my DAO methods are complex enough that I can > call my publically defined methods as helpers, which > leads to all sorts of problems. That would opening a > connection per call to a sibling method! > > What should be done here? > > I thought of moving the ownership of the connection > from the method to the instance level. Is this > appropriate? At least I could get sharing of a > connection. But some business layers call multiple > different DAO objects and it makes even more sense to > share a connection across all DAO objects. Would this > be better? I think so, but I don't know how to model > it. > > Please, any help! It is holding up my design. > > Thanks, > Paul > > > > __________________________________ > Yahoo! Mail > Stay connected, organized, and protected. Take the tour: > http://tour.mail.yahoo.com/mailtour.html > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
