Larry,
Very cute. Thanks for the partial credit. :)
Just remember: it's not what say, it's what I mean. :) And what I meant to
say was this:
Have a private variable that stores your DataSource reference in your
BaseDAO, ***NOT*** your connection (yes, I know, I wrote connection before,
so sue me :)). Then, have a getConnection() method in your BaseDAO that just
has this:
private Connection getConnection()
{
return myDatasource.getConnection();
}
In your DAO methods, you would have this:
{
.....
Connection myConnection = getConnection();
// do something with connection
finally
{
.....
myConnection.close();
}
}
This way, you only have to deal with ServiceLocator ONCE when you create
your DAO, so it will be even more efficient and clean.
Larry, do I get my 3rd point back? LOL (Common! I really need an A in this
course! :))
Thanks,
Yaakov.
-----Original Message-----
From: Larry Meadors [mailto:[EMAIL PROTECTED]
Sent: Friday, January 28, 2005 11:24 AM
To: Struts Users Mailing List
Subject: Re: Database Connection Workflow Question
On Fri, 28 Jan 2005 11:09:41 -0500, Chaikin, Yaakov Y. wrote:
> 1) I hope the code you showed is sitting inside a DAO, not your Action.
Heheh, me too. ;-)
> 2) It looks much messier because you are not using something like a
> ServiceLocator Pattern. Look up and cache the reference to your DataSource
> there. It's cleaner and way faster than doing it every time in your DAO.
For sure!
> 3) Also, to improve performance, you should probably store your connection
> in a private member variable in your DAO and have a base class for your
DAO
> with a getConnection() method. This way, any DAOs you implement that
extend
> from the BaseDAO will already know how to get the connection in a very
> efficient and clean way.
Hmm, OK, 2 out of 3 is not bad. :-)
I would never reccommend storing a private connection object in a DAO
- that is why we have DataSource objects. Get a connection, use it,
close it, and keep the open time to a minimum. Using a DataSource, you
can open and close connections for almost no cost (in terms of time).
In addition, unit testing that kind of architecture is a major PITA
because of the setup required.
Larry
---------------------------------------------------------------------
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]
