Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / Databases / August 2006

Tip: Looking for answers? Try searching our database.

Statement caching

Thread view: 
Markus Trenkle - 26 Aug 2006 10:14 GMT
Hi all,

I want to do multiple inserts/updates in a (Oracle) database. I use this
code:

...
final String query="update ...";
PreparedStatement stmt=conn.prepareStatement(query);
stmt.setString(1,string1);
stmt.executeUpdate();
stmt.setString(2,string2);
stmt.executeUpdate();
...
stmt.close();
...

So far this works fine. However I read the oracle docs recently abot
statement caching and all the examples use a stmt.close() between update
calls, e.g.

...
final String query="update ...?...";
PreparedStatement stmt1=conn.prepareStatement(query);
stmt1.setString(1,string1);
stmt1.executeUpdate();
stmt1.close();
PreparedStatement stmt2=conn.prepareStatement(query);
stmt2.setString(2,string2);
stmt2.executeUpdate();
stmt2.close();
...

This code is about 50% slower than mine above, even if I turn on
implicit statement caching in the oracle driver by using
conn.setImplicitStatementCache(true). Could someone please point out if
I am missing something important with my solution.

Also, I thought that by using a PreparedStatement the driver would send
it to the db immediately to do the optimizer stuff and the only waiting
for the bind variables to be submitted. There the Oracle doc suggests
that this is a JDBC-driver-thingy only.

Thank you for help,
Markus
Robert Klemme - 28 Aug 2006 14:32 GMT
> Hi all,
>
[quoted text clipped - 37 lines]
> for the bind variables to be submitted. There the Oracle doc suggests
> that this is a JDBC-driver-thingy only.

It might help if you provided a reference to the Oracle docs that you
are referring to.  IMHO using PreparedStatements for SQL statments
repeated during a session is the proper way to go.  I can't really
believe that Oracle documentation mandates closing statement objects in
between for this scenario.

Kind regards

    robert
Markus - 29 Aug 2006 14:34 GMT
> It might help if you provided a reference to the Oracle docs that you
> are referring to.

http://www.oracle.com/technology/sample_code/tech/java/sqlj_jdbc/files/basic/Dat
eSample/DateSample.java.html


This example is not about caching at all, however it uses
PreparedStatements and close() on them after a single use.

http://www.oracle.com/technology/sample_code/tech/java/sqlj_jdbc/files/jdbc30/St
mtCacheSample/StmtCacheSample.java.html


here close() is used with implicit statement caching (the comment
states that the statement is not closed physically, rather put into the
cache). Have tried this, not using close() at all is still faster for
me.

Thanks,
Markus
Robert Klemme - 29 Aug 2006 15:58 GMT
>> It might help if you provided a reference to the Oracle docs that you
>> are referring to.
[quoted text clipped - 3 lines]
> This example is not about caching at all, however it uses
> PreparedStatements and close() on them after a single use.

I think that example rather uses PST to avoid quoting and other issues
(i.e. be able to set parameters via setInt() etc.) and not to improve
performance.

> http://www.oracle.com/technology/sample_code/tech/java/sqlj_jdbc/files/jdbc30/St
mtCacheSample/StmtCacheSample.java.html

>
> here close() is used with implicit statement caching (the comment
> states that the statement is not closed physically, rather put into the
> cache). Have tried this, not using close() at all is still faster for
> me.

This can well be.  The driver likely has some overhead when caching
PreparedStatements etc.

Personally I don't like these samples too much as they are in part a bit
C-ish (predeclared variables etc.).

Personally I try to avoid using driver specific features if possible.
An alternative approach would be to create your own connection type that
does the caching and which can do that for all sorts of databases.  The
effort isn't too high and you can use it for every DB.  Maybe something
like this already exists somewhere.

Kind regards

    robert
kuassi.mensah@gmail.com - 29 Aug 2006 18:12 GMT
The driver automatically caches the PreparedStatement or the
CallableStatement objects upon the invocation of the close() method on
the statement object.
The cursors are kept after the closing of the statement objects and not
recreated for each new execution of the prepared or callable
statements.

The Oracle JDBC drivers furnish two statement caching methods: Implicit
(JDBC 3.0 compliant) and Explicit (Oracle specific). You are trying to
use the Implicit approach however, you must:
a) Invoke ((OracleConnection)conn).setImplicitCachingEnabled(true) on
the connection object.
b)Set the ImplicitCachingEnabled property to true and invoke
OracleDataSource.getConnection().

I have a complete description of both statement caching methods
(impicit, explicit), with working examples in my book
http://db360.blogspot.com/2006/08/oracle-database-programming-using-java_01.html

Kuassi

> Hi all,
>
[quoted text clipped - 40 lines]
> Thank you for help,
> Markus
Markus - 31 Aug 2006 17:02 GMT
kuassi.mensah@gmail.com schrieb:

> The driver automatically caches the PreparedStatement or the
...

Thank you for your answer. I already know that, in fact as I read the
Oracle documentation about this the above question came to my mind.

Before I used the PreparedStatement without close() at all, only the
description and examples from Oracle led me to believe, that my way of
doing things may be wrong.

Markus


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.