db-ojb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandre Borgoltz <alexandre.borgo...@smartjog.com>
Subject Re: Statement pooling
Date Thu, 09 Jun 2005 09:57:44 GMT
Thanks for the complete and fast answer, Martin!

 >Some JDBC-drivers already perform this on the client-side
I am using oracle8i with 8i client jar. Using that -thin- 8i JDBC driver 
, the performance tests show there is a huge difference between
*recreating a connection each time - obviously ultimately slow
*using a single connection but re-preparing a PreparedStatement with the 
same query - better
*using a single connection and a single PreparedStatement, only calling 
setXXX methods between calls to .executeQuery() - the best

I'll check it out very soon. Thanks again!


*Alexandre BORGOLTZ**
*Head of Technology

**SmartJog SA*
*Phone: +33 (0)1 4996 6324
Fax: +33 (0)1 4996 6405
Mobile: +33 (0)6 8882 1417
alexandre.borgoltz@smartjog.com <mailto:alexandre.borgoltz@smartjog.com>

Martin Kalén wrote:

> Alexandre Borgoltz wrote:
>> When accessing DB data, OJB uses a relatively small set of different 
>> queries. The default implementation uses PreparedStatement - which is 
>> a good thing :) with connection pooling.
>> I was wondering ig it was planned to use statement-level pooling to 
>> speed up thing even more? Is there an already existing implementation 
>> that uses statement pooling? Or maybe are there drawbacks in reusing 
>> statements in OJB?
> Some JDBC-drivers already perform this on the client-side, Oracle JDBC
> is an example of this. In the "Oracle9i" platform impl we set Oracle-
> specific statement caching (ie client-side pooling) and row pre-fetch
> directly from OJB.
> We have also added the possibility to use the Statement pool 
> functionality
> in Commons DBCP. This will be possible in the upcoming OJB 1.0.4 or if 
> you
> check out OJB from CVS from the OJB_1_0_RELEASE branch.
> (It should also be merged to CVS HEAD, it's only because my own lack of
> time that this did not happen yet.)
> You control Statement pooling by setting the following attributes on the
> connection pool in your repository_database:
>  "dbcp.poolPreparedStatements" to "true"
>  "dbcp.maxOpenPreparedStatements" to max # of statements in pool
>   (or "0" for no limit -- but beware of OutOfMemory exceptions!)
> See also the preview of the next site-documentation at the following URL
> (WARNING: transient content, please do not use for linking - this will
> be the next main OJB website):
>  http://people.apache.org/~mkalen/ojb/site/docu/guides/repository.html#Custom+attributes

> NB: You need to switch from the default ConnectionFactory to 
> ConnectionFactoryDBCPImpl
> in your OJB.properties for any custom dbcp.*-attributes to have any 
> effect.
> Both the default pooled OJB ConnectionFactory-implementation and the DBCP
> implementation use Commons Pool for the underlying object pools so 
> performance,
> configuration and behaviour will be very similar.
> Regards,
>  Martin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org

To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

View raw message