Not sure if this is really much help because I'm sure you've thought of this,
but I mirror many or all of my DB DAO methods with methods that take the
Connection as a parameter . . . In the primary method, they obtain their own
Connections, but in the secondary method, they use whatever Connection is
passed as a parameter. Then I have an adapter between the business manager and
the DAOs which obtains a Connection (and for example turns off autocommit),
passes it to many DAO methods, and then releases the Connection (after turning
autocommit back on).
If you are using Connection pooling though, the cost still may be very low and
not worth the trouble, as you are not really "opening" any Connections for each
DAO call -- the pool keeps them open all the time. When you get a Connection,
it comes from a cache. When you invoke close on the Connection, you are really
invoking close on an adapter which releases the Connection back to the cache .
. .
(But sometimes you need to share a Connection for another reason besides
optimization.)
Someone correct me if I'm wrong. Hope that helps, as I'm not familiar with the
Jakarta DAO stuff.
Erik
-----Original Message-----
From: Paul Benedict <[EMAIL PROTECTED]>
Sent: Aug 23, 2005 6:35 PM
To: user@struts.apache.org
Subject: [OT] DAO Pattern in Struts
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]
