db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mi...@apache.org
Subject svn commit: r962716 - in /db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests: master/updatelocksJDBC30.out tests/store/updateBtreeHoldCursorLocksJDBC30.subsql
Date Fri, 09 Jul 2010 22:46:09 GMT
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;



Mime
View raw message