I think having the DAO itself get the connection isn't an optimal
solution, most especially if it's happening in each method. Here's why...
I have one application in particular that is fairly complex and for a
given end-user function, I may have to use a couple of different business
delegates, which in turn may use a couple of different DAOs calling on a
couple of methods each. So, I may in fact have something like 10+
getConnection() calls during a single request (not all requests would be
like this of course, but some may). For the sake of scalability concerns,
I have to treat that like a single request is using 10 connections from
the pool, just to be safe. How big a pool can I have?!?
I think the better solution is to have a single class that gives you your
DAO, and which in turn feeds the DAO a connection object. This single
class, call it a DAOFactory since that seems pretty obvious, is
responsible for getting a connection from the pool and for ensuring that
any DAOs used during that request share the SAME connection. Now I'm down
to a single connection per request, regardless of how many business
delegates or DAOs are involved.
The way I personally choose to implement this pattern (I'm sure there's a
real name for it, but I don't know it off the top of my head) is this...
I have a base Action that all my "real" Actions extend from. It looks
something like this:
execute() {
DAOFactory daof = new DAOFactory();
try {
realExecute(m, f, r, r, daof);
} finally {
daof.cleanup();
}
}
In the real Actions, you'd see things like:
CustomerDAO cdao = (CustomerDAO)daof.getDAO("CustomerDAO");
ClientDAO cldao = (ClientDAO)daof.getDAO("ClientDAO");
When the DAOFactory is constructed, it pulls a connection from the pool.
When getDAO() is called, that connection is passed to the DAO. cleanup()
is of course responsible for returning the connection to the pool.
My actual implementation of this is a bit more complex with some further
flexibility, but that illustrates the basic underlying idea. I'm not
claiming this is some Earth-shattering new way of doing things or anything
like that, nor am I saying this is perfect and everyone should do it. I
wouldn't be surprised if there are problems with it (some will say there
is code in the Actions for instance, in the base Action specifically, that
shouldn't be there... I don't agree in this case). What I am saying
though is that this has worked out very well for me and is
production-tested in a high-volume, 24x7x365 app for over two years.
I'm only posting this in the hopes that my experience can benefit others,
it's not an attempt to say anyone else' approach is any less correct.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
On Fri, October 14, 2005 5:36 am, Leon Rosenberg said:
> I will try to answer for Larry :-)
>
> On 10/14/05, emre akbas <[EMAIL PROTECTED]> wrote:
>> Larry, I think you are using DAO. Then, I want to ask you how do you
>> deal
>> with the SQLException's and unclosed connections in your DAO classes if
>> you
>> are using JDBC as the persistence layer.
>>
>> Say, you have CustomerDAO and it has a insert method:
>>
>> public class CustomerDAO {
>> boolean insert() {
>> Connection con = getDataSource().getConnection();
>> .....
>> // an exception occurs here
>> ......
>> con.close();
>> }
>> }
>>
>
> boolean insert(){
> try{
> do_the_db_staff();
> }catch(SQLException e){
> log.error("insert", e);
> //do some recovering, maybe rollback
> throw new DAOException(e.getMessage());
> }finally{
> //do cleanup... like closing connections etc.
> }
> }
>
>
> regards
> Leon
>
>>
>> Do you catch this exception in the DAO method or do you throw it
>> outside?
>> When you throw it outside, the local connection will be unclosed. What
>> do
>> you to prevent such issues? Thanks in advance.
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Larry Meadors <[EMAIL PROTECTED]>
>> To: Struts Users Mailing List <user@struts.apache.org>
>> Date: Thu, 13 Oct 2005 08:36:47 -0600
>> Subject: Re: Struts and db connections :: best practice
>> I would argue that a well-written struts application will *never* (at
>> least 99.999% of the time) have jdbc code in it.
>>
>> Larry
>>
>>
>> On 10/13/05, emre akbas <[EMAIL PROTECTED]> wrote:
>> > Hi all,
>> > In a well written struts application, we assume declarative exception
>> > handling is used. Therefore the code of the action classes will look
>> clean
>> > and short (and nice) because all the exception handling is done via
>> the
>> > exception-handler classes outside. My question is about db connection
>> > management when declarative exception handling is used.
>> >
>> > A usual scenario is :
>> >
>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~
>> > public class MyAction extends Action {
>> > ...
>> > public ActionForward execute( . .. ) {
>> > ..
>> > Connection con = getDataSource().getConnection();
>> >
>> > // an exception occurs here and the control passes to the
>> > // exception-handler class, which can never close the connection
>> > // opened above.
>> > ....
>> >
>> > con.close();
>> > }
>> > ...
>> > }
>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> >
>> > What to do in a situation like above? Since the exception-handler
>> could
>> not
>> > close the connection opened in the Action class, this will cause the
>> > connections in the pool to be exhausted. To prevent the situation
>> above,
>> we
>> > may :
>> >
>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> > public class MyAction extends Action {
>> > ...
>> > public ActionForward execute( . .. ) {
>> > ..
>> > Connection con = null;
>> > try {
>> > con = getDataSource().getConnection();
>> >
>> > // an exception occurs here
>> > ....
>> >
>> > } catch(MyAppSpecifiException e) {
>> > ....
>> > } catch(Exception e) { // IMPORTANT, this line will catch all the
>> exceptions
>> > ....
>> > } finally {
>> > con.close();
>> > }
>> >
>> > }
>> > ...
>> > }
>> >
>> >
>> > The scheme above seems to solve the unclosed connection problem but it
>> does
>> > not use declarative exception-handling and the code is really
>> messed-up
>> with
>> > exception handling statements. It does not look nice, clean and short.
>> >
>> > The situation is more complicated when you call a service method
>> within
>> the
>> > action and that service method throws an exception.
>> >
>> > I would like to hear your points on this issuse. Thanks in advance.
>> >
>> >
>> > --
>> >
>> > Emre Akbas
>> >
>> >
>>
>>
>>
>> --
>> Emre Akbas
>>
>>
>
> ---------------------------------------------------------------------
> 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]
