Hi,
I'm done with Prepared-Statement Caching,
and I got it unit-tested as far as I can
possibly get.
It's a patch to PooledConnectionImpl,
containing the actual caching code,
a small patch to ConnectionWrapper,
delegating the "prepareStatement" call
to PooledConnectionImpl, and a new
class "PreparedStatementWrapper", which
is a proxy wrapper to the PreparedStatement
interface.
It successfully runs the unit test, with
the following exceptions which I investigated
all and found that these are problems
on their own.
In detail:
- I get one excpetion out of the Oracle-Driver
due to the effect which is explained on
BEA's docu-pages:
http://edocs.bea.com/wls/docs61/adminguide/jdbc.html#1133404
("Using setNull In a Prepared Statement")
I tracked that down and it's the DB-Attribute
ARTIST->ARTIST_NAME which is defined CHAR instead
of VARCHAR.
The unit test first does setNull on that attribute,
then another non-null set, and it happens exactly
what's explained on this BEA page, due to the
set-null with an "incorrect" type.
When changing that attribute from CHAR to VARCHAR,
everything is o.k.
- I get the same failure on the time-test which I already
know from removing the Oracle-"optimization" in
OracleSelectTranslator.
This cannot really be blamed on the prepared statement
caching, for me it just means that the
"defineColumnType" stuff is nonsense.
(How about just accepting that Oracle has a different
"opinion" on time-variables and relaxing this test?)
(The "defineColumnType" stuff in OracleSelectTranslator
really *kills* my performance on Oracle)
- I put a "sloppy" flag in PooledConnectionImpl
to avoid another unit-test-failure which
I think is due to unclosed statements
from iterated querys.
It works with that sloppyness, but
it would be better to debug this problem
and then set the sloppy-flag to false.
I implemented a limit on the number of cached statements
per connection. For the time being, I hardcoded that
number (maxStatements) in the constructor of
PooledConnectionImpl.
Making it a parameter in "datanode.driver.xml"
and propagating it to that constructor is not
really difficult, but means touching so many
classes that this is better done by someone
with a hand on the CVS.
maxStatements = 0 means caching is disabled.
The algorithm for the cache when it runs
on that limit is to close-and-forget
the statement unsused the longest time.
I think this is much more intelligent then
what BEA did (just stop filling the cache).
With my application I get a simple
Oracle select query down from 4ms to 2ms
when switching on prepared-statement
caching, so it's a sizable effect.
Maybe there's a volunteer to test,
integrate, and commit this patch?
thanks,
Arndt
This archive was generated by hypermail 2.0.0 : Sat Mar 29 2003 - 06:35:40 EST