TAGS :Viewed: 7 - Published at: a few seconds ago

[ Trying to use connection pooling outside servlet engine ]

I have a series of methods running within a servlet engine (Tomcat in this case), using connection pooling to access the database written in this way:

// Gets an RSS_Feed.
public static RSS_Feed get(int rssFeedNo) {
    ConnectionPool_DB pool = ConnectionPool_DB.getInstance();
    Connection connection = pool.getConnection();
    PreparedStatement ps = null;
    ResultSet rs = null;

    String query = ("SELECT * " +
                    "FROM RSS_Feed " +
                    "WHERE RSSFeedNo = ?;");

    try {
        ps = connection.prepareStatement(query);
        ps.setInt(1, rssFeedNo);
        rs = ps.executeQuery();
        if (rs.next()) {
            return mapRSSFeed(rs);
        }
        else {
            return null;
        }
    }
    catch(Exception ex) {
        logger.error("Error getting RSS_Feed " + rssFeedNo + "\n", ex);
        return null;
    }
    finally {
        Database_Utils.closeResultSet(rs);
        Database_Utils.closeStatement(ps);
        pool.freeConnection(connection);
    }
}

Is it possible to call such a method outside of the servlet engine at all? I would like to do this in a batch process executed from the command line instead of within the servlet engine. I know I could simply rewrite the query without connection pooling but this is one of many queries involved in the process.

The connection pooling is implemented via Apache Common DBCP.

ConnectionPool_DB.getInstance(); reads:

private ConnectionPool_DB() {
    try {
        InitialContext ic = new InitialContext();
        dataSource = (DataSource) ic.lookup(PropertiesFile.getProperty("myApp", "DATASOURCE"));
        // dataSource = (DataSource) ic.lookup("java:/comp/env/jdbc/myApp");
    }
    catch(Exception ex) {
        logger.error("Error getting a connection pool's datasource\n", ex);
    }
}

Answer 1


I have something like this in a project:

Context ctx = new InitialContext(); 
DataSource ds = (DataSource) ctx.lookup("DbConnection");
ConnectionPool connectionPool = new ConnectionPool(ds)

And inside context xml I define the resouce like this

<Resource name="DbConnection" 
auth="SERVLET" 
type="javax.sql.DataSource"  
scope="Shareable"            
driverClassName="**driverClassName**" 
url="**url**" 
username="**username**" 
password="**password**" 
maxActive="10" 
maxIdle="10" 
maxWait="1000"
/>

So I assume you have something similar If so you need to write code to create the DataSource yourself.

This should help you with that http://docs.oracle.com/javase/tutorial/jdbc/basics/sqldatasources.html

Answer 2


Do you mean that you want to share a connection pool between your servlet engine and a batch job? Or that you want to use connection pooling within a batch job?

As to sharing a pool between Tomcat and a batch job: Hmm, I don't see how you'd do it. Tomcat and the batch job would each have their own instance of the Java Virtual Machine. They're not sharing memory, classes, etc, so I don't know where such a common pool would live.

If you mean within a batch job: Sure. I think such a thing is rarely necessary. In batch jobs I normally open a connection at the start of the program and close it at the end. There's not much value to creating a connection pool. Desktop apps are a little trickier. I often create a connection when the app starts and close it when they exit, but arguably this ties up a connection when the user is just staring blindly at the screen (like I often do for the hour or so before lunch), so other times I open a connection every time the user clicks a key that causes something to happen, then release it before going back to "wait" mode. Again, there's little point pooling because in a desktop app, there are no other users to share the pool with.

But can it be done? Sure. I've done it in desktop apps where many things could happen at various times and so it was awkward to pass a single connection around.

Answer 3


Sure, it could be used may be with slightly modification of the JNDI connectivity. But the Tomcat should run.