Re: OutOfMemoryErrors when testing Derby with DOTS

[Craig L Russell]

Hi John,

On Jan 30, 2006, at 12:11 PM, John Embretsen wrote:

Monday, January 30, 2006, 7:46:42 PM, Craig L Russell wrote:

Hi,

On Jan 27, 2006, at 4:11 PM, Ramandeep Kaur wrote:

Hi,

As per Stan's mail about prepared statements, I checked the source
code for DOTS test case that John ran (ATCJ2.java) to see if
prepared statements are getting closed properly. I found that there
are few methods in ATCJ2.java where prepared statements are not
getting closed.

In addition, in doBid() method,
pstmt.close(); and pstmt = null; should be added right after the
following block.

pstmt = conn.prepareStatement(updateBidItemSQL + "'" + itemID + "'");

Any reason why itemID is bound to the preparedStatement and not
itself passed as a parameter?

Generally, preparing statements like this (those that include
parameters) just before use has little benefit. The big win is to
prepare the statement and then reuse it everywhere. So if you change
the updateBidItemSQL to include the itemID as a ? parameter, then

pstmt.setInt(3, itemID) you will get the benefit of prepared statements.

Craig

I am fully aware of this rather strange and inefficient use of

in this thread:

 "I don't know the rationale behind doing it this way. It may be just
 "sloppy code", or it may be intentional."

PreparedStatements in the DOTS test case. As I stated in my first E- mail

ps.setInt(...);
ps.execute();





Craig

I was trying to be nice. I'll reiterate my point. If your use of prepared statements is limited to the following pattern: PreparedStatement ps = conn.prepare(savedSQLStatement + "" + itemID + ""); then you are not taking advantage of prepared statements. Your prepared statement cache is not doing any good at all. This is the hammer that is making your head hurt. Before you can see if aspirin helps, put down the hammer.

I guess we have to ask the creators of DOTS for the answer. I have not
made any inquiries in this regard as of this time. However, DOTS is a
part of the Open Source project called "The Linux Test Project", which
is "a joint project started by SGI™ and maintained by IBM®"

( http://ltp.sourceforge.net/ ), so I guess nothing stops us from doing

so...


handle code of this type without running out of memory within a
relatively short period of time. I guess that since (even) the DOTS

the future. I would (with help from the Derby community) like to get

resolved, and I intend to provide as much information as I can in this
regard.

Having said that, I would like to point out that Derby is obviously
not the only DB with such problems, see Q4 under "Q&A" in the DOTS
User's Guide: http://ltp.sourceforge.net/dotshowto.php#SEC42


--
John

However, my main concern right now is that Derby is not robust enough to creators wrote such code, other Derby users may be inclined to do so in this issue into the open and (if it is agreed that it is a Derby issue)

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature