Thank you for your interest. Here it is: ==============================
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE sqlMapConfig PUBLIC "-//ibatis.apache.org//DTD SQL Map Config 2.0//EN" "http://ibatis.apache.org/dtd/sql-map-config-2.dtd";> <sqlMapConfig> <properties resource="ibatis.properties" /> <settings cacheModelsEnabled="true" enhancementEnabled="true" lazyLoadingEnabled="true" useStatementNamespaces="false" /> <transactionManager type="JDBC"> <dataSource type="DBCP"> <property name="driverClassName" value="${driver}"/> <property name="url" value="${url}"/> <property name="username" value="${username}"/> <property name="password" value="${password}"/> <property name="logAbandoned" value="true"/> <property name="removeAbandoned" value="true"/> <property name="removeAbandonedTimeout" value="1"/> <property name="Driver.logUnclosedConnections" value="true"/> </dataSource> </transactionManager> <sqlMap resource="swingCat-sqlMap.xml" /> </sqlMapConfig> ============================== Larry Meadors wrote: > > Can you post the sqlmapconfig.xml? > > On Mon, Oct 19, 2009 at 1:44 PM, Jim Borland <jborl...@calpoly.edu> wrote: >> >> No, I'm not smart enough to use a DAO implementation (I've read a little >> about them). Also, I keep reading about Spring -- a whole bunch of stuff >> on >> it comes up when I Google on these topics. Someday I'm going to check >> into >> Spring. >> >> My situation is very simple and it seems like plain old iBatis ought to >> be >> plenty for me in this application. iBatis is supposed to take care of >> all >> the background stuff and just let me write mapped statements. I'm >> committed >> to making iBatis work without a bunch of extra stuff. Thanks for your >> interest in my problem. >> >> >> Warren Bell-2 wrote: >>> >>> 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 >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/iBatis---Connections-to-PostgreSQL-Not-Closing-tp25943619p25964382.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 >> >> > > --------------------------------------------------------------------- > 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-tp25943619p25964622.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
