Yeah, but usually a table will have more than 65 records, so retrieve by
primary key is still worthy to use PreparedStatement.
I think the difficulty is that where to cache preparedstatement. The
preparedstatement is only live within a connection, so if the connection is
returned to the pool, the next time it may get another connection which
don't come with that preparedstatement cached.

----- Original Message -----
From: "Nathan Bronson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 11, 2002 11:52 AM
Subject: Re: [castor-dev] Castor performance concern


>
> JW>After developing using castor for a while, I become more concerned
> JW>about its performance, As far as I know:
> JW>1. Castor don't support the use of preparedstatement, it always use
> JW>statement to load a object by key
>
> Chapter 19 of O'Reilly's Oracle JDBC book is available online and includes
> some performance comparisons between Statement, PreparedStatement, and
> CallableStatement, as well as a comparison between the Oracle thick and
> thin drivers.  Their experiments were done with inserts instead of
> selects, but they suggest that the breakeven point for using
> PreparedStatements is pretty high (65 inserts for the OCI driver in their
> experiment).  PreparedStatements can be cached by some drivers so you
> might not have to execute a statement 65 times in a single transaction in
> order to get a performance benefit, but for many applications Statement
> will be faster.
>
>    http://www.oreilly.com/catalog/jorajdbc/chapter/ch19.html
>
> ..snip..
>
> ----------------------------------------------------
> Nathan Bronson                       [EMAIL PROTECTED]
> "Once you get above 100 feet, it doesn't matter"
>
> -----------------------------------------------------------
> 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

Reply via email to