Reuse of preparedstatements and the connection pool

Question

It seems useful (for performance reasons) to reuse a prepared statement in
subsequent calls to the database. In WebLogic, however, after each call we
return the Connection object to the WebLogic connection pool. A prepared
statement is created on a specific Connection object. The next time we want
to use the same query we get a Connection from the pool, which might be
another instance of the Connection class. Therefor it seems impossible or at
least dangerous to reuse the same prepared statement. Even in the case this
would work we're indirectly using the other Connection, which we already
returned to the pool and which could be retrieved from the pool by someone
else. So, can't we reuse preparedstatements ?

Answer 1

Hi Raja,
Currently the only bullet-proof way to make sure that all statements are
cached is to set the cache size to a number of possible prepared statements
in the application.
The only consequence of increased cache size is growing amount of
memory required by a server instance.
Regards,
Slava Imeshev
"Rajiv Jauhari" <[email protected]> wrote in message
news:[email protected]...
Is there an easy way to tell whether the prepared statement cache size one
has set is
appropriate? Some way to monitor cache hit rate or usage count (i.e., the
actual number of statements cached) while running a load test? I'm using
Weblogic 6.1sp3 and Oracle 8.1.7.4.
Another way to think of this question is: is there a negative impact ifthe
cache size is set too large?
In the case of Oracle I believe one might run out of cursors, but is there
any other negative consequence that you know of?
Thanks,
Rajiv
"Joseph Weinstein" <[email protected]> wrote in message
news:[email protected]...
Vyas wrote:
If multiples (of the same statement) can be cached would it not result
in too many
prepared statements of the same type in the cache ?
This could happen
1. When a load test is done when all the threads start doing exactly
the
same work.
Because of contention everybody gets their own statement copy(theoritically, even
if in practice it may not exactly happen like that). In such a case
you
are going
to create load on the database in terms of open cursors.Each thread will get it's own connection, and the statement cache isper-connection.
Cursors, in Oracle's case, do need to be configured to support acache-full of
retained statements. Alternately, the cache should be set to a smallenough size to
require only as many cursors as the DBMS will allow per connection.
Another issue is what happens when the cache limit is hit ?
In the above example let's say cache limit is 50 and I am doing 50
user
load test.
because of load test let's say the cache gets filled with 50 of the
same
statement.
When load test moves to the next sequence of action requiring a
diffrent
statement
what happens to the cache ?
thanks
VyasThe only way a given connection's statement cache will get a duplicatestatement
is if some single JDBC thread required multiple copies of the samestatement. A
multi-user test will usually just ensure that each pooled connectioncaches the
same selection of different statements that the test user used. If thetest user
just repeatedly makes and uses one statement, the first time they do it,the
statement will be cached, and every subsequent repeat of the user codewill get
the same cached statement. The cache will still have 49 empty slotswaiting for
different statements. Currently the cache is simple-minded. It is a
fixed
(configurable)
size per connection, and the first N prepared/callable statements getcached for the
life of the pooled connection that created them. All other subsequentstatements will
be made and closed on a per-connection-use basis. Therefore, it can bethat a startup
or stress load that runs before standard runtime service, and which usessignificantly
different a statement profile could populate the cache with rarely-usedwasted statements.
If I were a customer in this circumstance, I would either prime thecaches, by determining
which statements I wanted cached, and then running a startup class thatreserved all the
pool connections, and made these statements on each before closing them.Alternately,
after startup/stress I would reset the pool, and allow the runtime load
to
fill the cache of
the regenerated pool.
Joe Weinstein at B.E.A.
thanks
Vyas
Joseph Weinstein <[email protected]> wrote:
JS wrote:
It seems useful (for performance reasons) to reuse a prepared
statement
in
subsequent calls to the database. In WebLogic, however, after each
call
we
return the Connection object to the WebLogic connection pool. A
prepared
statement is created on a specific Connection object. The next timewe
want
to use the same query we get a Connection from the pool, which
might
be
another instance of the Connection class. Therefor it seemsimpossible
or at
least dangerous to reuse the same prepared statement. Even in the
case
this
would work we're indirectly using the other Connection, which we
already
returned to the pool and which could be retrieved from the pool bysomeone
else. So, can't we reuse preparedstatements ?We already have you covered! Weblogic caches PreparedStatements along
with the pooled connection they came from. Every time you obtain a
pool
connection and run a prepareStatement() or prepareCall(), we willtransparently
give you a previously made statement, if the SQL exactly matches, andno
other place in the current thread stack is using that statement(multiples
can
be cached)
You are correct, of course, that statements you have should only
be
useable
to you while you have the connection from which they came. We have
you
covered
there too. If you were to try to use any prepared statement that
you'd
gotten
from
a pool connection after you'd put the connection back into the pool,those
statements
would throw an exception saying that they had been made inoperable atthe
time
you'd closed the connection.
Joe Weinstein at B.E.A.