IIRC, Struts2 actions are not singletons.  So this code is creating a
new instance of the SqlMapClient (and it's associated connection pool)
each time you hit the web page.  They will eventually get cleaned up
by the GC, but that might take a while.

Better would be to implement ApplicationAware also, then write code like this:

SqlMapClient sqlMap = (SqlMapClient) applicationMap.get("sqlMap");
if (sqlMap == null) {
     try {
        sqlMap =
SqlMapClientBuilder.buildSqlMapClient(Resources.getResourceAsReader("sqlMaps.xml"));
       applicationMap.put("sqlMap", sqlMap);
     } catch (Exception e)  {
        e.printStackTrace();
     }
}

Make sure all other actions use this same code - a good use for a
super class :).  Then you know it's only created once.

Jeff Butler




On Mon, Oct 19, 2009 at 3:28 PM, Jim Borland <jborl...@calpoly.edu> wrote:
>
> Here it is.  Thanks for your interest in my situation.  Using Apache Struts2
> - this is an action implementation.  The call is to "listOfArtists" in class
> "ListSwingCatAction"
>
> =============================
>
> public class ListSwingCatAction implements SessionAware
> {
>   private SqlMapClient sqlMap;
>   private SwingCatIBatisDBHandler myDBHandler;
>   private Map sessionMap;
>
>   public ListSwingCatAction()
>   {
>      try
>      {
>         sqlMap =
> SqlMapClientBuilder.buildSqlMapClient(Resources.getResourceAsReader("sqlMaps.xml"));
>      }
>      catch (Exception e)
>      {
>         e.printStackTrace();
>      }
>      myDBHandler = new SwingCatIBatisDBHandler(sqlMap);
>   }
>
>   public String listOfArtists()
>   {
>      ArrayList artists = myDBHandler.getArtistInfo();
>      sessionMap.put("artists", artists);
>      return "success";
>   }
> }
>
> =============================
>
>
> Jeff Butler-2 wrote:
>>
>> We should also see the Java code that creates the SqlMapClient.
>> Without Spring you need to make sure that only a SINGLE instance of
>> that object is created (it should be and stored either in a singleton
>> or something like a web context).
>>
>> Jeff Butler
>>
>> On Mon, Oct 19, 2009 at 2:50 PM, Larry Meadors <larry.mead...@gmail.com>
>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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-tp25943619p25965093.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

Reply via email to