In an off-line email conversation with Rick Wellman I've been inspired to rethink one of my assumptions. Up until now I've assumed that the "Finalizing a Connection that was never closed" message is due to having an abandoned connection, and happens because I have:
--> <property name="removeAbandoned" value="true"/> in my <sqlMapConfig> file. Maybe that's not the case. Could this just be the normal action of a connection pool purging itself of excess connections? 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 > > > -- View this message in context: http://www.nabble.com/iBatis---Connections-to-PostgreSQL-Not-Closing-tp25943619p25964938.html Sent from the iBATIS - User - Java mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org For additional commands, e-mail: user-java-h...@ibatis.apache.org
