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 16:06:57 GMT
Craig L Russell wrote:

> If this test code is representative of the actual application, then  the 
> application is in trouble and should be reimplemented in the jdbc  area. 
> It is a very well-understood requirement of well-behaved  applications 
> that result sets and prepared statements and connections  be closed when 
> they are no longer needed. And testing what happens to  ill-behaved 
> applications in various configurations doesn't seem to be  a good use of 
> anyone's energy.

I disagree (obviously, since I have already spent some energy running 
these tests). At least when such ill-behaved applications may cause 
serious trouble for other users, which is the case when the Derby 
Network Server collapses because it runs out of memory (correct me if 
I'm wrong).

> Long term, I don't believe that Derby or any other implementation  
> should try to optimize for applications written without regard for  good 
> programming patterns.

I agree with Dan's comment on this. For example, I don't regard 
DERBY-210 as an optimization issue.

> That said, OutOfMemoryError is unfortunate, but perhaps unavoidable.  
> Does the test succeed, given enough memory? Does closing the result  
> sets and prepared statements change the behavior? 

More testing is needed to find this out for sure...

> How can Derby know  
> whether you intend to use the result set and prepared statement  again, 
> and you actually want to keep them open? Do you want Derby to  
> internally close result sets and prepared statements that it guesses  
> you no longer want? In a large system, wouldn't it be a bug in Derby  if 
> Derby closed result sets and prepared statements that the  application 
> still wanted?

To the last question: I guess so.

I'll leave the rest of your questions to someone who has more experience 
with and knowledge about Derby and database systems in general than I do 
at the moment ;) I  think there are some ongoing discussions about this, 
e.g. DERBY-210 and DERBY-817.

>>> This is the hammer that is making your head hurt. Before you can see
>>> if aspirin helps, put down the hammer.
>> Personally, I would prefer a database with a strong enough helmet to
>> withstand such hammer hits. Someone else may find that hammer one
>> day, and hit you again ;)
> These particular hammers are in an area clearly marked "Danger: Use  of 
> these hammers may be injurious to your sanity". ;-)

That does not necessarily prevent "insane carpenters" from using them. 
Let me reiterate the scenario in which multiple users are accessing a 
Derby Network Server:

If a malicious user (yes, they exist) would want to perform, say, a 
Denial of Service attack against this server, all they have to do is to 
run such an application!

OK, this is not a valid scenario in _all_ environments, but that's not 
the point I'm trying to make.

> Seriously, if you are trying to evaluate different databases'  behavior 
> under a simulated application scenario, you should try to  duplicate in 
> your tests how the application actually behaves. And if  the test is 
> shown to have programming anomalies, and fixing the test  informs better 
> behavior in the application, then I'd say the test  succeeded. After 
> removing the anomalies in the test, you can see the  underlying behavior 
> of the system in various configurations, and have  a better way to 
> evaluate alternatives.

I agree, to a certain extent. But, my goal of testing Derby is to find 
potential flaws/weaknesses in Derby, and/or to verify that a certain 
version of Derby is able to do/handle certain things. In this particular 
case, DOTS happened to be at my disposal, so I used it. It was not my 
primary goal to test Derby in a particular application scenario.


View raw message