Are you using any DAO implementation ? Spring? Makes things much simpler.
Warren
Jim Borland wrote:
I've been fighting this issue for a long time now and am quite frustrated. I
originally started out with just:
--> artists = (ArrayList) sqlMap.queryForList("getArtistInfo", list ); --
but was getting all these <IDLE> connections. So I tried adding
start/commit/end transaction statements surrounding the query. Still
getting <IDLE>s so then I tried using :
--> session = sqlMap.openSession(); -- and letting the session
start/commit/end the transaction. Still got <IDLE>s. That's when I tried
creating, using and closing my own connection with the same sad result.
One thing Rick Wellman said was especially interesting. Every time you
create an instance of SqlMapClient you create an entirely new connection
pool. I hadn't thought about that before. I guess the bottom line is I
don't really understand what is happening in a connection pool. Still, my
situation is so simple, yet the same bad outcome occurs no matter what I
try. Help!
Rick.Wellman wrote:
Since I have some time over lunch:
1) I agree with Larry's reply below
2) At the risk of embarrassing myself on this forum, see below for my
reply to your comments and questions:
[your-code-sample-was-here]
[your-comments-were-here]
I've been wrestling with this problem for a long time and right now
there are three things about which I wonder:
(1) All the code examples I've seen show the sqlMapClient being
generated in the same try statement as the actual query. I'm creating it
in a separate class and passing it to another class. Could this be a
problem? I'm not sure why it would matter, but that is something unique
about my situation.
Usually, your entire application would share a single instance of
SqlMapClient. It matters in the sense that it is un-necessary and
would, at a minimum, create an entirely new connection pool (see #3 for
more)
(2) In the above code I use the DataSource obtained from SqlMapClient --
Is there something wrong with doing this?
Well, probably... and it is un-necessary. Use Larry's version. (i.e.
the "normal" way to use the SqlMapClient)
(3) Have I somehow mis-configured the connection pool?
I could be wrong but I still highly suspect that the connections are
a result of the connection pool and it seems to me that you're not
understanding the purpose of a connection pool. i.e. You're trying to
explicitly open a connection with code. The connection pool will
usually expand and contract the number of connections to the database
based on the load and its configuration (which is why it is called a
"pool"). You do not have "direct" control over which connection your
iBatis SqlMapClient will use [nor do you probably want that]. I
apologize in advance if I am way off base with this response; not my
intent to offend, but rather educate.
To the masses... in regards to my comment #3, is there an implementation
of a "pool" which is not a pool at all but a single connection that
someone can use to verify an instance like this? Or maybe configure the
"pool" to only have a size of one? Just thinking out loud... I've never
had reason to look into something like this but it seems like this
question comes up every so often? (i.e. the question of connections
opened via iBatis)
-----Original Message-----
From: Larry Meadors [mailto:larry.mead...@gmail.com]
Sent: Monday, October 19, 2009 12:56 PM
To: user-java@ibatis.apache.org
Subject: Re: iBatis - Connections to PostgreSQL Not Closing
This looks to me like you are *way* overcomplicating this. :-)
The method should be more like this:
public List getArtistInfo(){
return sqlMap.queryForList("getArtistInfo", list);
}
Unless you have some really crazy wacky stuff going on, there should
never be a need for you to deal with connections at that level.
Also, what's the purpose of passing in 'list' as the second parameter
there? I don't see where it would ever be non-null.
Larry
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
For additional commands, e-mail: user-java-h...@ibatis.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
For additional commands, e-mail: user-java-h...@ibatis.apache.org
--
Thanks,
Warren Bell
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
For additional commands, e-mail: user-java-h...@ibatis.apache.org
