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 Mon, 30 Jan 2006 18:46:42 GMT
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

> pstmt.setFloat(1,bidPrice);
> pstmt.setInt(2,bidCount++);
> updateCount = pstmt.executeUpdate();
> DotsConfig.UPDATECOUNT++;
>
> Now with patch DERBY-210, there may not be any need to modify DOTS  
> code as all garbage collection will be taken care, but in case you  
> still see problems even after applying patch DERBY-210, you might  
> want to give a try to modify the ATCJ2.java.
>
> Also, please increase heap size while running Network Server as well.
>
> Thanks,
> Ramandeep Kaur (ramandhindsa@gmail.org)
>
> On 1/27/06, Deepa Remesh <dremesh@gmail.com> wrote:
> On 1/27/06, John Embretsen <John.Embretsen@sun.com> wrote:
> > Friday, January 27, 2006, 6:14:12 PM, Deepa Remesh wrote:
> >
> > > Hi John,
> >
> > > After a quick read of your mail, it seems to me some of the
> > > OutOfMemoryErrors you are seeing may be because of the leak  
> described
> > > in DERBY-210. I have a patch for this attached to the JIRA  
> issue. If
> > > it is okay, can you please try re-running the tests after applying
> > > this patch? I think it should make some difference in the memory
> > > usage.
> >
> > OK, I will give it a try next week, thanks!
>
> Thanks. I saw you were running tests with 10.1.2.1. The patch attached
> to DERBY-210 is for the trunk.
>
> > Do you (or anyone else) know what kind of OutOfMemoryError you are
> > seeing with regards to that Jira issue? (Java Heap Space, PermGen  
> space,
> > ...)
> >
>
> The OutOfMemoryError seen with DERBY-210 is for Java Heap Space. This
> happens if an application which uses client driver does not explicitly
> close statements. With 64MB heap space, I get OutOfMemoryError after
> executing ~950 prepared statements.
>
> Deepa

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