struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vic Cekvenich <>
Subject Re: What's the best choice for connection pooling with Struts and PostgreSQL
Date Sun, 02 Nov 2003 19:18:50 GMT
1. It is a good practice to use the containers data source pool via 
JNDI. Application servers like Tomcat, Resin, OrionServer, etc all 
provide a "service" to the web app of a connection pool. You should not 
code one, but use one.
        Context ctx = new InitialContext();
        DataSource ds = (DataSource) ctx.lookup("java:comp/env/mypool");
        conn = ds.getConnection();

And you configure the pool in the container. Ex in Resin 3.03:
     <driver type="org.postgresql.jdbc3.Jdbc3ConnectionPool" >

The idea here is that you deploy same web app to staging or production, 
without changing the app.

2. You do not need to do #1 above either. Just like you use Struts and 
not code to servlets, you should not code to JDBC. You should use a DAO, 
such as (SQL based and my favorite) or Hibrenate.
Ex in iBatis:
List _resList;
_resList = _sqlMap.executeQueryForList("xmlNamedSQLquerry");

And you have a List of results. The JNDI, pool open and close it done 
for you, you just work on your result list (that you can pass on to 
display tag for example)

J2EE designed real nice and you should leverage it, not fight it.


ZYD wrote:
> Dear all,
> I'm writing my Struts application using PostgreSQL as the backend database. Could you
give me some advice on choosing the connection pooling framework/methods?
> I wrote my own connection pooling classes, but if there are some good frameworks from
jakarta, it definitely worth a  try.
> Any response is greatly appreciated.
> bruce

Victor Cekvenich,
Struts Instructor
(215) 321-9146

Advanced Struts Training
<> Server Side Java
training with Rich UI, mentoring, designs, samples and project recovery
in North East.
Simple best practice basic Portal, a Struts CMS, Membership, Forums,
Shopping and Credit processing, <> software, ready
to develop/customize; requires a db to run.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message