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.These particular hammers are in an area clearly marked "Danger: Use of these hammers may be injurious to your sanity". ;-)This is the hammer that is making your head hurt. Before you can seeif 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 ;)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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
