When I considered that... it was more pain than gain.

Lots of possible side effecets to consider and not a great
performance gain in general.

Paulo

> -----Original Message-----
> From: Johan Compagner [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 31, 2001 19:13
> To: struts dev
> Subject: PreparedStatements pool.
>
>
> Hi,
>
> I was just wondering if i gane much when i also pool all my
> PreparedStatements.
>
> Now i  get a connections of the pool in a method.
> In that method i created a PreparedStatement.
> set some values in it
> and execute it.
> Sometimes that preparedstatement is reused because it is in a lus.
>
> But now everytime i come in that method a new PreparedStatement
> is created.
> So why not pool them in the GenericConnection?
> The prepareStatement method:
>
> public PreparedStatement prepareStatement(String sql) throws
> SQLException {
>  if (closed) throw new SQLException(SQLEXCEPTION_CLOSED);
>  return (conn.prepareStatement(sql));
> }
> change to this:
>
> public PreparedStatement prepareStatement(String sql) throws
> SQLException {
>  if (closed) throw new SQLException(SQLEXCEPTION_CLOSED);
> PreparedStatement statement = null;
>  synchronize(_hmStatements)
> {
>      statement =  _hmStatemen.remove(sql);
> }
> if(statement == null)
> {
>     statement = new
> PooledPreparedStatement(this,conn.prepareStatement(sql));
> }
>  return statement;
> }
>
> and the close of the PooledPreparedStatement class add's that statement to
> the pool.
>
> The problem is that a PreparedStatement is attached to one Connection.
> So when i have 4 connections for pooling then i get 4 the same prepared
> statements
> for every connection 1.
>
> And if you use a lot of kind's of PreparedStatements over time. A lot of
> statements
> are open. Does the database mind?
>
> If this is not the right approace,
> How else should PreparedStatements be pooled?
>
> Johan Compagner
>
>
>
>
>

Reply via email to