excalibur datasource: PreparedStatement caching

[Greg Steuck <gr...@nest.cx>]

>>>>> "Peter" == Peter Royal <pr...@apache.org> writes:

    Peter> Thats fine. My only suggestion would be to also implement a
    Peter> prepared statement cache so if the same prepared statement
    Peter> was asked for again, just return the existing instance :)

I feel this feature is on a different level. We will need to have a map
of released (closed) PreparedStatements associated with each connection.
The PreparedStatements will be wrapped into a decorator that intercepts
close() and returns the statements into the map (closing any pending
ResultSets first). I don't think that a PreparedStatement can be reused
until the original caller disposes of it.

IMHO, the benefit of such cache is not obvious and I would much rather
defer this kind of caching to the database vendor JDBC implementation.

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

Re: excalibur datasource: PreparedStatement caching

[Peter Royal <pr...@apache.org>]

On Thursday, February 6, 2003, at 12:47  AM, Greg Steuck wrote:
> IMHO, the benefit of such cache is not obvious and I would much rather
> defer this kind of caching to the database vendor JDBC implementation.

thats fine. I believe JDBC 3 has some pooling that the JDBC implementor 
can do. Berin started working with this on a new data source package in 
the scratchpad.
-pete

-- 
peter royal -> proyal@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org