You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by mi...@apache.org on 2010/07/10 00:46:09 UTC
svn commit: r962716 - in
/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests:
master/updatelocksJDBC30.out
tests/store/updateBtreeHoldCursorLocksJDBC30.subsql
Author: mikem
Date: Fri Jul 9 22:46:08 2010
New Revision: 962716
URL: http://svn.apache.org/viewvc?rev=962716&view=rev
Log:
DERBY-4211 derbyall/encryptionAll/storemats.fail:store/updatelocksJDBC30.sql' fails with unexpected locks
The problem was the timing of post commit cleanup of deleted rows. If the
test beat the post commit thread then it would "see" the deleted rows and
need to lock them. By waiting after the commit of the deleted rows the
results should now be consistent in the rows seen after the commit of the
delete.
Before the fix it repro'd 3 out of 100 runs. After the fix it passed 300 out
of 300 times, so assuming it is fixed.
Modified:
db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out
db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateBtreeHoldCursorLocksJDBC30.subsql
Modified: db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out?rev=962716&r1=962715&r2=962716&view=diff
==============================================================================
--- db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out (original)
+++ db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out Fri Jul 9 22:46:08 2010
@@ -1142,6 +1142,12 @@ APP |UserTran|ROW |2 |X |A
APP |UserTran|ROW |2 |X |A |(1,12) |GRANT|ACTIVE
APP |UserTran|ROW |2 |X |A |(1,8) |GRANT|ACTIVE
ij> commit;
+ij> -- in order to get consistent locking results, wait for the post commit
+-- thread to finish processing the committed deleted rows. Otherwise
+-- the subsequent scans get timing dependent lock results dependent on
+-- if the background post commit gets to the deleted rows first or not.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
ij> select * from lock_table order by tabname, type desc, mode, cnt, lockname;
USERNAME|TRANTYPE|TYPE |CNT |MODE|TABNAME |LOCKNAME |STATE|STATUS
---------------------------------------------------------------------------
@@ -2034,6 +2040,12 @@ APP |UserTran|ROW |2 |X |A
APP |UserTran|ROW |2 |X |A |(1,12) |GRANT|ACTIVE
APP |UserTran|ROW |2 |X |A |(1,8) |GRANT|ACTIVE
ij> commit;
+ij> -- in order to get consistent locking results, wait for the post commit
+-- thread to finish processing the committed deleted rows. Otherwise
+-- the subsequent scans get timing dependent lock results dependent on
+-- if the background post commit gets to the deleted rows first or not.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
ij> select * from lock_table order by tabname, type desc, mode, cnt, lockname;
USERNAME|TRANTYPE|TYPE |CNT |MODE|TABNAME |LOCKNAME |STATE|STATUS
---------------------------------------------------------------------------
@@ -3615,6 +3627,12 @@ APP |UserTran|ROW |2 |X |A
APP |UserTran|ROW |2 |X |A |(4,6) |GRANT|ACTIVE
APP |UserTran|ROW |2 |X |A |(6,6) |GRANT|ACTIVE
ij> commit;
+ij> -- in order to get consistent locking results, wait for the post commit
+-- thread to finish processing the committed deleted rows. Otherwise
+-- the subsequent scans get timing dependent lock results dependent on
+-- if the background post commit gets to the deleted rows first or not.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
ij> select * from lock_table order by tabname, type desc, mode, cnt, lockname;
USERNAME|TRANTYPE|TYPE |CNT |MODE|TABNAME |LOCKNAME |STATE|STATUS
---------------------------------------------------------------------------
@@ -4501,6 +4519,12 @@ APP |UserTran|ROW |2 |X |A
APP |UserTran|ROW |2 |X |A |(4,6) |GRANT|ACTIVE
APP |UserTran|ROW |2 |X |A |(6,6) |GRANT|ACTIVE
ij> commit;
+ij> -- in order to get consistent locking results, wait for the post commit
+-- thread to finish processing the committed deleted rows. Otherwise
+-- the subsequent scans get timing dependent lock results dependent on
+-- if the background post commit gets to the deleted rows first or not.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
ij> select * from lock_table order by tabname, type desc, mode, cnt, lockname;
USERNAME|TRANTYPE|TYPE |CNT |MODE|TABNAME |LOCKNAME |STATE|STATUS
---------------------------------------------------------------------------
@@ -6290,6 +6314,12 @@ APP |UserTran|ROW |2 |X |A
APP |UserTran|ROW |2 |X |A |(1,12) |GRANT|ACTIVE
APP |UserTran|ROW |2 |X |A |(1,8) |GRANT|ACTIVE
ij> commit;
+ij> -- in order to get consistent locking results, wait for the post commit
+-- thread to finish processing the committed deleted rows. Otherwise
+-- the subsequent scans get timing dependent lock results dependent on
+-- if the background post commit gets to the deleted rows first or not.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
ij> select * from lock_table order by tabname, type desc, mode, cnt, lockname;
USERNAME|TRANTYPE|TYPE |CNT |MODE|TABNAME |LOCKNAME |STATE|STATUS
---------------------------------------------------------------------------
@@ -7307,6 +7337,12 @@ APP |UserTran|ROW |2 |X |A
APP |UserTran|ROW |2 |X |A |(1,12) |GRANT|ACTIVE
APP |UserTran|ROW |2 |X |A |(1,8) |GRANT|ACTIVE
ij> commit;
+ij> -- in order to get consistent locking results, wait for the post commit
+-- thread to finish processing the committed deleted rows. Otherwise
+-- the subsequent scans get timing dependent lock results dependent on
+-- if the background post commit gets to the deleted rows first or not.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
ij> select * from lock_table order by tabname, type desc, mode, cnt, lockname;
USERNAME|TRANTYPE|TYPE |CNT |MODE|TABNAME |LOCKNAME |STATE|STATUS
---------------------------------------------------------------------------
@@ -9129,6 +9165,12 @@ APP |UserTran|ROW |2 |X |A
APP |UserTran|ROW |2 |X |A |(4,6) |GRANT|ACTIVE
APP |UserTran|ROW |2 |X |A |(6,6) |GRANT|ACTIVE
ij> commit;
+ij> -- in order to get consistent locking results, wait for the post commit
+-- thread to finish processing the committed deleted rows. Otherwise
+-- the subsequent scans get timing dependent lock results dependent on
+-- if the background post commit gets to the deleted rows first or not.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
ij> select * from lock_table order by tabname, type desc, mode, cnt, lockname;
USERNAME|TRANTYPE|TYPE |CNT |MODE|TABNAME |LOCKNAME |STATE|STATUS
---------------------------------------------------------------------------
@@ -10148,6 +10190,12 @@ APP |UserTran|ROW |2 |X |A
APP |UserTran|ROW |2 |X |A |(4,6) |GRANT|ACTIVE
APP |UserTran|ROW |2 |X |A |(6,6) |GRANT|ACTIVE
ij> commit;
+ij> -- in order to get consistent locking results, wait for the post commit
+-- thread to finish processing the committed deleted rows. Otherwise
+-- the subsequent scans get timing dependent lock results dependent on
+-- if the background post commit gets to the deleted rows first or not.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
ij> select * from lock_table order by tabname, type desc, mode, cnt, lockname;
USERNAME|TRANTYPE|TYPE |CNT |MODE|TABNAME |LOCKNAME |STATE|STATUS
---------------------------------------------------------------------------
@@ -11715,6 +11763,12 @@ USERNAME|TRANTYPE|TYPE |CNT |MODE|TAB
APP |UserTran|TABLE |6 |IX |A |Tablelock |GRANT|ACTIVE
APP |UserTran|TABLE |1 |X |A |Tablelock |GRANT|ACTIVE
ij> commit;
+ij> -- in order to get consistent locking results, wait for the post commit
+-- thread to finish processing the committed deleted rows. Otherwise
+-- the subsequent scans get timing dependent lock results dependent on
+-- if the background post commit gets to the deleted rows first or not.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
ij> select * from lock_table order by tabname, type desc, mode, cnt, lockname;
USERNAME|TRANTYPE|TYPE |CNT |MODE|TABNAME |LOCKNAME |STATE|STATUS
---------------------------------------------------------------------------
@@ -12588,6 +12642,12 @@ USERNAME|TRANTYPE|TYPE |CNT |MODE|TAB
APP |UserTran|TABLE |6 |IX |A |Tablelock |GRANT|ACTIVE
APP |UserTran|TABLE |1 |X |A |Tablelock |GRANT|ACTIVE
ij> commit;
+ij> -- in order to get consistent locking results, wait for the post commit
+-- thread to finish processing the committed deleted rows. Otherwise
+-- the subsequent scans get timing dependent lock results dependent on
+-- if the background post commit gets to the deleted rows first or not.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
ij> select * from lock_table order by tabname, type desc, mode, cnt, lockname;
USERNAME|TRANTYPE|TYPE |CNT |MODE|TABNAME |LOCKNAME |STATE|STATUS
---------------------------------------------------------------------------
@@ -14250,6 +14310,12 @@ APP |UserTran|ROW |2 |X |A
APP |UserTran|ROW |2 |X |A |(4,6) |GRANT|ACTIVE
APP |UserTran|ROW |2 |X |A |(6,6) |GRANT|ACTIVE
ij> commit;
+ij> -- in order to get consistent locking results, wait for the post commit
+-- thread to finish processing the committed deleted rows. Otherwise
+-- the subsequent scans get timing dependent lock results dependent on
+-- if the background post commit gets to the deleted rows first or not.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
ij> select * from lock_table order by tabname, type desc, mode, cnt, lockname;
USERNAME|TRANTYPE|TYPE |CNT |MODE|TABNAME |LOCKNAME |STATE|STATUS
---------------------------------------------------------------------------
@@ -15381,6 +15447,12 @@ APP |UserTran|ROW |2 |X |A
APP |UserTran|ROW |2 |X |A |(4,6) |GRANT|ACTIVE
APP |UserTran|ROW |2 |X |A |(6,6) |GRANT|ACTIVE
ij> commit;
+ij> -- in order to get consistent locking results, wait for the post commit
+-- thread to finish processing the committed deleted rows. Otherwise
+-- the subsequent scans get timing dependent lock results dependent on
+-- if the background post commit gets to the deleted rows first or not.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
ij> select * from lock_table order by tabname, type desc, mode, cnt, lockname;
USERNAME|TRANTYPE|TYPE |CNT |MODE|TABNAME |LOCKNAME |STATE|STATUS
---------------------------------------------------------------------------
Modified: db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateBtreeHoldCursorLocksJDBC30.subsql
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateBtreeHoldCursorLocksJDBC30.subsql?rev=962716&r1=962715&r2=962716&view=diff
==============================================================================
--- db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateBtreeHoldCursorLocksJDBC30.subsql (original)
+++ db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateBtreeHoldCursorLocksJDBC30.subsql Fri Jul 9 22:46:08 2010
@@ -152,6 +152,13 @@ close scan_cursor;
select * from lock_table order by tabname, type desc, mode, cnt, lockname;
commit;
+
+-- in order to get consistent locking results, wait for the post commit
+-- thread to finish processing the committed deleted rows. Otherwise
+-- the subsequent scans get timing dependent lock results dependent on
+-- if the background post commit gets to the deleted rows first or not.
+CALL WAIT_FOR_POST_COMMIT();
+
select * from lock_table order by tabname, type desc, mode, cnt, lockname;
commit;
select a from a;