tomcat-users mailing list archives

Hi, Filip,

My tomcat jdbc pool is configured in my app's context.xml. My app uses MyBatis
3 to do the work. I store MyBatis SqlSessionFactory in ServletContext
attributes. 

I was able to get DataSources back from Batis SqlSessionFactory, and invoke
.close on each. The leak seems to have gone away now.

Thanks again for your help.

ps. Here's a snippet, in case anyone runs a similar configuration

import java.io.IOException;
import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import org.apache.ibatis.io.Resources;
import org.apache.ibatis.session.SqlSessionFactory;
import org.apache.ibatis.session.SqlSessionFactoryBuilder;
import org.apache.tomcat.jdbc.pool.DataSource;

/**
 * Initialize MyBatis Configuration in this application
 * 
 * <p> Loads mybatis configuration for d1 and d2 Databases. Per user manual, 
 * configures one {@link SqlSessionFactory} per Database and stores the factories 
 * in the context attributes <code>smsSqlSessionFactory</code> and 
 * <code>riSqlSessionFactory</code>
 *
 * @author nsushkin
 * @see http://blog.idleworx.com/2010/06/initialize-mybatis-servletcontextlisten.html
 */
public class MyBatisConfiguratingContextListener implements javax.servlet.ServletContextListener
{

    @Override
    public void contextInitialized(ServletContextEvent sce)
    {
        ServletContext ctx = sce.getServletContext();
        String myBatisConfigFile = "…/mybatis-configuration.xml";

        try
        {
            ctx.setAttribute("sf1",
                    new SqlSessionFactoryBuilder().build(Resources.getResourceAsReader(myBatisConfigFile),
"env1"));

            ctx.setAttribute("sf2", 
                    new SqlSessionFactoryBuilder().build(Resources.getResourceAsReader(myBatisConfigFile),
"env2"));
        
        }
        catch (IOException ex)
        {
            ctx.log("Unable to configure MyBatis from config file `" + myBatisConfigFile +
"'",
                    ex);
        }
    }

    @Override
    public void contextDestroyed(ServletContextEvent sce)
    {
        ServletContext ctx = sce.getServletContext();
        closeDataSource(ctx, "sf1");
        closeDataSource(ctx, "sf2");
        ctx.removeAttribute("sf1");
        ctx.removeAttribute("sf2");
    }
    
    private void closeDataSource(ServletContext ctx, String contextAttribute)
    {
        DataSource dataSource = (DataSource)((SqlSessionFactory) ctx.getAttribute(contextAttribute)).getConfiguration().getEnvironment().getDataSource();
        dataSource.close();
    }
}

On Thursday, March 03, 2011 11:17:43 Filip Hanik - Dev Lists wrote:
> hi Nicholas,
> where is your pool configured? In server.xml or in your application
> context? If it is configured in server.xml, then this is a bug, the thread
> should have been created with the class loader from the pool itself. If it
> is configured in the application context, then this simply means you
> forgot to call DataSource.close on the connection pool when your web
> application is stopped.
> 
> best
> Filip

-- 
Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations
Open Finance Aggregation eXchange <http://www.aggex.com>