|
Duplicate of
Agreed, same "signature" as reported by Jørgen.
Ole, do you have the .out file from the failure? I am not able to reproduce and maybe the output will give a clue as to the problem. Also there is an ongoing discussion regarding this test in
I would like to move the test back to derbyall until it can be properly converted to JUnit with the low memory heap. Unfortunately now it is not testing what it was intended to test because it runs with the heap allocated by the suite jvm. I don't know if such a move would make any difference in the intermittent failure. Dan are you still opposed to the move back to derbyall given my comments in This is the fail/Embedded_40/JDBCHarnessJavaTest/derbyStress/derbyStress.out:
Test derbyStress starting Testing with 2000 prepared statements PASS -- Prepared statement test FAIL -- unexpected exception **************** SQLSTATE(X0X95): Operation 'DROP TABLE' cannot be performed on object 'TAB' because there is an open ResultSet dependent on that object. from one of todays failures. I have also copied the full log for this run to http://dbtg.thresher.com/derby/test/debug/612869_sles_suitesAll.zip Hope this helps. Thanks Ole, that helps alot. The test intentionally does not close ResultSets to test for the leak, but this was causing a problem dropping the table. With revision 613275 I changed the test to close the last ResultSet and force a gc(). Hopefully this will take care of the problem. I will leave the issue open a couple of days to make sure it has gone away. Please post if you see any problem.
Kathey > With revision 613275 I changed the test to close the last ResultSet and force a gc().
Adding the forced gc() seems to be a case of making the test pass rather than fixing a potential bug. Adding a gc() to the test is really saying it's part of the api, and thus this is what applications need to do as well. Since this is not what is required (ie. we don't want to have to say in order to run Derby successfully you need to force gc() once in a while), can we remove the gc() and then fix the bug if the problem remains? Even closing the ResultSet has the feel of making the test pass rather than fixing a potential bug. Is there a valid explanation for why holding this result set open stops the table being dropped? If there is then it's acceptable to close the result set, but if the ResultSet being open should have no effect on the DROP TABLE then we are merely avoiding seeing a bug by closing the ResultSet. The ResultSets were open and accessing the table and needed to be closed or garbage collected before that reference was eliminated. I did not close the ResultSets as part of the test because I needed to leave them open to test for the leak. It seems reasonable that we were getting the error on drop table if the ResultSets were still referencing the table and not yet garbage collected, so I forced the gc() to allow the table to be dropped. Users would typically need to close all ResultSets referring to a table before the dropped it, I think.
This failure is still seen on the 10.3 branch: e.g. http://dbtg.thresher.com/derby/test/statistics/3323_today.html (today = 2008-01-21):
http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.4/FailReports/613633_bySig.html http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.5/FailReports/613633_bySig.html I hestitated to port the fix to 10.3 because Dan had some concerns with the fix. He especially did not like the gc, but it seems to me that as long as there are open result sets referring to the table it cannot be dropped. Dan, do you have another recommendation for removing these references so we can drop the table?
depending on isolation level and the state of the open results set it would totally be expected that this would stop
a drop from happening. It gets confusing with the various row caches around, but from the bottom up what is expected for read committed: while a result set is open store will hold a IS table intent lock until the result set is closed. This lock will conflict with drop table and thus will cause the drop table to block until the result set is closed. It will usually hold one read committed row lock with is the "current" row in the scan. From store point of view the result set can get closed in one of 2 ways, either by explicitly closing it or by "nexting" past the last row in the result set. Correlating the second condition is hard from the client side as multiple level of caching (drda and internal "group fetch") make it to tell the relationship between the "current" row in the application and the actual last row that has been fetched from store. Is the System.gc() required? If so we probably need to document this as part of DROP TABLE.
However I think that would be a really bad idea, I thought that Derby itself went through and tried to perform gc() if there were open result sets during such an operation. looking more carefully at the error message I don't think the locking is was is causing the drop error (what I described would likely be the case if the drop and the result sets were in different connections), but instead
probably the dependency manager. My assumption would be that disallowing this ddl is necessary otherwise one would get strange behavior in the resultset which depends on a stable ddl for the tables in the result set while the result set is open. We do document:
"The existence of an open cursor that references table being dropped cause the DROP TABLE statement to generate an error, and the table is not dropped." Which as a user I would read as not closed, either explicitly or by garbage collection. I don't think that it is a bug that DROP TABLE does not attempt garbage collection, but do think it would be a nice improvement. We do so for SET TRANSACTION ISOLATION. Should I file a issue to have Derby attempt garbage collection if it detects open result sets when attempting DROP TABLE? I thought DROP TABLE did perform gc since GenericLanguageConnectionContext.verifyNoOpenResultSets does and I thought that's what DROP TABLE would end up calling.
I'm curious, do you know why & where gc() is called for SET TRANSACTION ISOLATION, I can't see the connection ... The gc() happens in GenericLanguageConnectionContext.verifiyAllHeldResultSetsAreClosed() which is called from GenericLanguageConnectionContext.setIsolationLevel(). I missed the gc() in verifyNoOpenResultSets().
I don't think we can rely on System.gc() actually freeing and finalizing all unreferenced objects. Its javadoc says that calling the method "suggests that the Java Virtual Machine expend effort toward recycling unused objects" and that it will make a "best effort to reclaim space". Calling it in verifyNoOpenResultSets() as a last attempt before failing is OK, I think, since it increases the likelihood of being able to perform the operation successfully. On the other hand, if a test depends on the side-effects from System.gc() in order to pass, I think it will be inherently unstable (as seen in
It's not a bug that DROP TABLE fails, in my opinion, since JDBC only guarantees that a ResultSet releases its resources when it has been closed, and the test code resembles a user error, as it does not close the ResultSets and holds resources for an unnecessarily long period. I'd suggest that the cleanup code instead closes the connection (which ensures that all its database and JDBC resources are released, according to its javadoc), and performs DROP TABLE in a different connection. Attached is a patch which incorporates Knut's suggestion to close the connection to cleanup the result sets. (Thanks Knut!). I hope this is acceptable to all.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Minor
ComparisonFailure in derbyStress
Rerunning just JDBCHarnessJavaTest saw it pass (Solaris 10/x86, JVM 1.6).