db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Embretsen <John.Embret...@Sun.COM>
Subject Re: OutOfMemoryErrors when testing Derby with DOTS
Date Wed, 01 Feb 2006 15:11:35 GMT
Michael Segel wrote:

> I think that there are two issues. One how Derby handles itself and attempts 
> to clean up stale objects.
> The second is that whoever wrote the test didn't know what they were doing.
> So that question is: "Should Derby be smart enough to protect bad programmers 
> from themselves?".

And representatives from both the "yes" and "no" camps have provided 
arguments in this thread, which is good I guess :) I believe this is not 
an either/or issue, but that it has to be considered on a case-by-case 

There is also the question of protecting _other_ Derby users from "bad 
programmers" (e.g. in a multi-user Client/Server environment where one 
Derby Network Server is shared by multiple users with their own 
databases and/or JDBC client applications accessing these databases), 
which I think is important to consider.

> With respect to both issues, any solution will increase the footprint of 
> Derby.  This may be a bad thing.

As you can see from my recent comment to DERBY-210, the patch Deepa has 
uploaded to that issue eliminated the OutOfMemory error I was reporting, 
at least for the first 24 hours (using the same test setup) of the test run.

As far as I know, the patch changes just a few things in the client, 
which in my case increased the footprint of derbyclient.jar by a 
negligible amount (around 50 bytes). So in this particular case, it was 
  not a very bad thing, in my opinion. I understand your concern, though.

> So the better question is... do you blame the hammer or the carpenter when he 
> can't hit a nail straight in to the wood?

Who to blame is IMHO not the most important thing if the house falls 
down on the person who lives there because of this.


View raw message