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
