db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mi...@apache.org
Subject svn commit: r962848 - in /db/derby/code/branches/10.6: ./ java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out java/testing/org/apache/derbyTesting/functionTests/tests/store/updateBtreeHoldCursorLocksJDBC30.subsql
Date Sat, 10 Jul 2010 14:20:42 GMT
Author: mikem
Date: Sat Jul 10 14:20:42 2010
New Revision: 962848

URL: http://svn.apache.org/viewvc?rev=962848&view=rev
Log:
DERBY-4211 derbyall/encryptionAll/storemats.fail:store/updatelocksJDBC30.sql' fails with unexpected
locks

merged fix #962716 from trunk to 10.6 codeline.

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/branches/10.6/   (props changed)
    db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out
    db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateBtreeHoldCursorLocksJDBC30.subsql

Propchange: db/derby/code/branches/10.6/
------------------------------------------------------------------------------
--- svn:mergeinfo (original)
+++ svn:mergeinfo Sat Jul 10 14:20:42 2010
@@ -1,2 +1,2 @@
-/db/derby/code/trunk:938547,938796,938959,939231,940462,940469,941627,942031,942286,942476,942480,942587,944152,946794,948045,948069,951346,952138,952237,954344,954421,954544,954748,955001,955634,956075,956234,956445,956569,956659,957260,958163,958618,959550
+/db/derby/code/trunk:938547,938796,938959,939231,940462,940469,941627,942031,942286,942476,942480,942587,944152,946794,948045,948069,951346,952138,952237,954344,954421,954544,954748,955001,955634,956075,956234,956445,956569,956659,957260,958163,958618,959550,962716
 /db/derby/docs/trunk:954344

Modified: db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out?rev=962848&r1=962847&r2=962848&view=diff
==============================================================================
--- db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out
(original)
+++ db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out
Sat Jul 10 14:20:42 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/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateBtreeHoldCursorLocksJDBC30.subsql
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateBtreeHoldCursorLocksJDBC30.subsql?rev=962848&r1=962847&r2=962848&view=diff
==============================================================================
--- db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateBtreeHoldCursorLocksJDBC30.subsql
(original)
+++ db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateBtreeHoldCursorLocksJDBC30.subsql
Sat Jul 10 14:20:42 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