db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: OutOfMemoryErrors when testing Derby with DOTS
Date Tue, 31 Jan 2006 02:03:38 GMT
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
> PreparedStatements in the DOTS test case. As I stated in my first E- 
> mail
> 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."

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 +  
"");
ps.setInt(...);
ps.execute();

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.

Craig

>
> 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...
>
> However, my main concern right now is that Derby is not robust  
> enough to
> handle code of this type without running out of memory within a
> relatively short period of time. I guess that since (even) the DOTS
> creators wrote such code, other Derby users may be inclined to do  
> so in
> the future. I would (with help from the Derby community) like to get
> this issue into the open and (if it is agreed that it is a Derby  
> issue)
> 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
>

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


Mime
View raw message