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 
basis.

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.


-- 
John

Mime
View raw message