On Sun, 12 Jan 2003 20:24:04 -0500, tek1 wrote: > > > in a servlet environment, if obtaining a new Database object for each > > > method (or call from a servlet) is the correct approach, how does this > > > impact performance since it seems that 1 Database object = 1 database > > > connection. if that is the case, should a pool of Database objects be used > > > in such an environment? if so, are there any existing projects (i.e. > > > jakarta commons) that offer such pooling ability? > >Why not rely on the pooling mechanism of your container, i.e. jboss in > >your case. Just setup and configure a JDBC connection pool, and make it > >available to Castor b ytelling Castor to obtain JDBC connections from a > >specified enrty in a JNDI naming tree ? That way, the overhead > >associated to obtaining fresh Database instances for each thread should > >be minimal. > > good point. i will look into this. in the case where a container is not > used and thus no pooling, does castor itself provide Database (connection) > pooling or is that the responsibility of the application using castor? > just wondering if something like jakarta's commons pool > (http://jakarta.apache.org/commons/pool.html) should be used in a non-app > server environment?
I am not really an expert on using Castor in standalone mode, so I'll leave it up to others to step in and share their views, but the default behaviour of Castor in this mode is to use a new JDBC connection (or Database instance) for each call of JDO.getDatabase(). Having said that, please have a close look at http://castor.exolab.org/database-conf.html (The Castor configuration file) and you'll see that there is three supported modes of telling Castor how to obtain Database connections. The second one (using the <data-source> element) allows you to use a class that implements the javax.sql.DataSource interface. That could well be a separate pool manager implementation or a vendor-specific DataSource implementation that supports pooling (e.g. IBM's DB2PooledDataSource). I hope this helps. Werner > > thank you again. > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
