Glassfish depends on the JDBC driver to do the caching, on the theory
that the JDBC driver will need to do caching to support Java SE
programs, so duplicating the caching in the appserver is redundent.
For Oracle's JDBC drivers, you need to set these properties when
defining your JDBC pool:
ImplicitCachingEnabled=true
MaxStatements=200
[You can use whatever number you think you'll need for max statements.]
-Scott
On Fri, 2008-02-22 at 10:46, Mei Wu wrote:
> Does Glassfish datasource have PreparedStatement Caching in connection pool?
> I mean data source optimizes the processing of prepared statements by
> managing a pool of database connections, as well as an associated cache
> of prepared statement objects. Prepared statements are cached separately
> for each connection that executes them.
>
> From my test using oracle, if I do normally like create a connection,
> does PreparedStatement, commit connection, close PreparedStatement and
> close connection, the throughput is 30% lower than if I cache the the
> connection and PreparedStatement in the application itself and use it in
> multiple transactions, which I don't think is a recommended practice
> while using the connection pooling in app server.
>
> Thanks
> Mei
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>