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 Wed, 01 Feb 2006 16:31:09 GMT

On Feb 1, 2006, at 8:06 AM, John Embretsen wrote:

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

I think the only disagreement here is what we think is being tested.  
If we think we are testing well-behaved applications and trying to  
make decisions based on the results, then I disagree. If we think we  
are testing ill-behaved applications and trying to see how well the  
system under test responds, then I agree.

In fact, having an ill-behaved application bring a server down is a  
useful exercise. And there are improvements that we should make based  
on the test. Just let's not think that we're evaluating normal behavior.
>
>
>> 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.
> http://issues.apache.org/jira/browse/DERBY-210

I agree.
>
>> 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...

Looking at DERBY-210, I infer that the DOTS test would eventually  
fail after all available memory was exhausted.
>
>> 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.

I agree.
>
>
>> 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.

Again, I want to say that I came into this discussion late, and was  
originally under the impression that you had an application that you  
were looking to optimize. I apologize if my comments took everyone  
off track.

Craig

>
>
> -- 
> John
>

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