db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mi...@apache.org
Subject svn commit: r1245725 - in /db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests: master/ tests/store/
Date Fri, 17 Feb 2012 19:36:27 GMT
Author: mikem
Date: Fri Feb 17 19:36:26 2012
New Revision: 1245725

URL: http://svn.apache.org/viewvc?rev=1245725&view=rev
Log:
DERBY-5599 readlocks.sql fails with extra locks.

backported #1245056 from trunk to 10.8 branch.

readlocks checks for expected locks in a number of scenarios. Intermittently
it could see extra locks if it happened to check the lock table, while the
background thread was running reclaiming deleted rows. This is most likely
in the tests that put a single row per page, delete some rows, commit and
then shortly after do work and check the lock table.

Added workaround used other places which waits for post commit to finish
after the commit following the deletes. Have updated all the places I saw
where the problem is likely - not just the one causing the diff reported
in this JIRA.

Changes affect the readlocks test and the updatelocksJDBC30 test. 


Modified:
    db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out
    db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out
    db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql
    db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql
    db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql
    db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql

Modified: db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out?rev=1245725&r1=1245724&r2=1245725&view=diff
==============================================================================
--- db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out (original)
+++ db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out Fri Feb 17 19:36:26 2012
@@ -508,6 +508,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -1021,6 +1030,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> select a, b, c from a;
 A          |B          |C                                                                                                                               
 --------------------------------------------------------------------------------------------------------------------------------------------------------
@@ -1535,6 +1553,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -2360,6 +2387,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -3668,6 +3704,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -4181,6 +4226,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> select a, b, c from a;
 A          |B          |C                                                                                                                               
 --------------------------------------------------------------------------------------------------------------------------------------------------------
@@ -4694,6 +4748,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -5511,6 +5574,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -6831,6 +6903,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -7351,6 +7432,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> select a, b, c from a;
 A          |B          |C                                                                                                                               
 --------------------------------------------------------------------------------------------------------------------------------------------------------
@@ -7874,6 +7964,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -8717,6 +8816,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -10038,6 +10146,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -10554,6 +10671,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> select a, b, c from a;
 A          |B          |C                                                                                                                               
 --------------------------------------------------------------------------------------------------------------------------------------------------------
@@ -11076,6 +11202,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -11910,6 +12045,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -13337,6 +13481,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -13918,6 +14071,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> select a, b, c from a;
 A          |B          |C                                                                                                                               
 --------------------------------------------------------------------------------------------------------------------------------------------------------
@@ -14554,6 +14716,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -15546,6 +15717,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -17057,6 +17237,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -17638,6 +17827,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> select a, b, c from a;
 A          |B          |C                                                                                                                               
 --------------------------------------------------------------------------------------------------------------------------------------------------------
@@ -18273,6 +18471,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -19257,6 +19464,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -20667,6 +20883,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -21188,6 +21413,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> select a, b, c from a;
 A          |B          |C                                                                                                                               
 --------------------------------------------------------------------------------------------------------------------------------------------------------
@@ -21710,6 +21944,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -22574,6 +22817,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -23950,6 +24202,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -24471,6 +24732,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> select a, b, c from a;
 A          |B          |C                                                                                                                               
 --------------------------------------------------------------------------------------------------------------------------------------------------------
@@ -24992,6 +25262,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks
@@ -25856,6 +26135,15 @@ ij> ------------------------------------
 delete from a where a = 2 or a = 4 or a = 6;
 3 rows inserted/updated/deleted
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+0 rows inserted/updated/deleted
 ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 0 rows inserted/updated/deleted
 ij> -- RESOLVE: missing row locks

Modified: db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out?rev=1245725&r1=1245724&r2=1245725&view=diff
==============================================================================
--- db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out (original)
+++ db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out Fri Feb 17 19:36:26 2012
@@ -393,6 +393,15 @@ APP     |UserTran|ROW     |1   |X   |A  
 APP     |UserTran|ROW     |1   |X   |A           |(1,12)    |GRANT|ACTIVE  
 APP     |UserTran|ROW     |1   |X   |A           |(1,8)     |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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  
 ---------------------------------------------------------------------------
@@ -685,6 +694,15 @@ APP     |UserTran|TABLE   |3   |IX  |A  
 APP     |UserTran|ROW     |1   |X   |A           |(1,13)    |GRANT|ACTIVE  
 APP     |UserTran|ROW     |1   |X   |A           |(1,7)     |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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  
 ---------------------------------------------------------------------------
@@ -793,6 +811,15 @@ APP     |UserTran|TABLE   |3   |IX  |A  
 APP     |UserTran|ROW     |1   |X   |A           |(1,11)    |GRANT|ACTIVE  
 APP     |UserTran|ROW     |1   |X   |A           |(1,9)     |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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  
 ---------------------------------------------------------------------------
@@ -2882,6 +2909,15 @@ APP     |UserTran|ROW     |1   |X   |A  
 APP     |UserTran|ROW     |1   |X   |A           |(2,7)     |GRANT|ACTIVE  
 APP     |UserTran|ROW     |1   |X   |A           |(3,7)     |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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  
 ---------------------------------------------------------------------------
@@ -3174,6 +3210,15 @@ APP     |UserTran|TABLE   |3   |IX  |A  
 APP     |UserTran|ROW     |1   |X   |A           |(1,7)     |GRANT|ACTIVE  
 APP     |UserTran|ROW     |1   |X   |A           |(4,6)     |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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  
 ---------------------------------------------------------------------------
@@ -3282,6 +3327,15 @@ APP     |UserTran|TABLE   |3   |IX  |A  
 APP     |UserTran|ROW     |1   |X   |A           |(2,6)     |GRANT|ACTIVE  
 APP     |UserTran|ROW     |1   |X   |A           |(3,6)     |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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  
 ---------------------------------------------------------------------------
@@ -5440,6 +5494,15 @@ APP     |UserTran|ROW     |1   |X   |A  
 APP     |UserTran|ROW     |1   |X   |A           |(1,12)    |GRANT|ACTIVE  
 APP     |UserTran|ROW     |1   |X   |A           |(1,8)     |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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  
 ---------------------------------------------------------------------------
@@ -5770,6 +5833,15 @@ APP     |UserTran|ROW     |1   |U   |A  
 APP     |UserTran|ROW     |1   |X   |A           |(1,13)    |GRANT|ACTIVE  
 APP     |UserTran|ROW     |1   |X   |A           |(1,7)     |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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  
 ---------------------------------------------------------------------------
@@ -5884,6 +5956,15 @@ APP     |UserTran|ROW     |1   |U   |A  
 APP     |UserTran|ROW     |1   |X   |A           |(1,11)    |GRANT|ACTIVE  
 APP     |UserTran|ROW     |1   |X   |A           |(1,9)     |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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  
 ---------------------------------------------------------------------------
@@ -8295,6 +8376,15 @@ APP     |UserTran|ROW     |1   |X   |A  
 APP     |UserTran|ROW     |1   |X   |A           |(2,7)     |GRANT|ACTIVE  
 APP     |UserTran|ROW     |1   |X   |A           |(3,7)     |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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  
 ---------------------------------------------------------------------------
@@ -8625,6 +8715,15 @@ APP     |UserTran|ROW     |1   |U   |A  
 APP     |UserTran|ROW     |1   |X   |A           |(1,7)     |GRANT|ACTIVE  
 APP     |UserTran|ROW     |1   |X   |A           |(4,6)     |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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  
 ---------------------------------------------------------------------------
@@ -8739,6 +8838,15 @@ APP     |UserTran|ROW     |1   |U   |A  
 APP     |UserTran|ROW     |1   |X   |A           |(2,6)     |GRANT|ACTIVE  
 APP     |UserTran|ROW     |1   |X   |A           |(3,6)     |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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  
 ---------------------------------------------------------------------------
@@ -11068,6 +11176,15 @@ USERNAME|TRANTYPE|TYPE    |CNT |MODE|TAB
 APP     |UserTran|TABLE   |3   |IX  |A           |Tablelock |GRANT|ACTIVE  
 APP     |UserTran|TABLE   |1   |X   |A           |Tablelock |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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  
 ---------------------------------------------------------------------------
@@ -11341,6 +11458,15 @@ USERNAME|TRANTYPE|TYPE    |CNT |MODE|TAB
 APP     |UserTran|TABLE   |2   |IX  |A           |Tablelock |GRANT|ACTIVE  
 APP     |UserTran|TABLE   |1   |X   |A           |Tablelock |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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  
 ---------------------------------------------------------------------------
@@ -11443,6 +11569,15 @@ USERNAME|TRANTYPE|TYPE    |CNT |MODE|TAB
 APP     |UserTran|TABLE   |2   |IX  |A           |Tablelock |GRANT|ACTIVE  
 APP     |UserTran|TABLE   |1   |X   |A           |Tablelock |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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  
 ---------------------------------------------------------------------------
@@ -13485,6 +13620,15 @@ USERNAME|TRANTYPE|TYPE    |CNT |MODE|TAB
 APP     |UserTran|TABLE   |3   |IX  |A           |Tablelock |GRANT|ACTIVE  
 APP     |UserTran|TABLE   |1   |X   |A           |Tablelock |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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  
 ---------------------------------------------------------------------------
@@ -13758,6 +13902,15 @@ USERNAME|TRANTYPE|TYPE    |CNT |MODE|TAB
 APP     |UserTran|TABLE   |2   |IX  |A           |Tablelock |GRANT|ACTIVE  
 APP     |UserTran|TABLE   |1   |X   |A           |Tablelock |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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  
 ---------------------------------------------------------------------------
@@ -13860,6 +14013,15 @@ USERNAME|TRANTYPE|TYPE    |CNT |MODE|TAB
 APP     |UserTran|TABLE   |2   |IX  |A           |Tablelock |GRANT|ACTIVE  
 APP     |UserTran|TABLE   |1   |X   |A           |Tablelock |GRANT|ACTIVE  
 ij> commit;
+ij> -- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+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.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql?rev=1245725&r1=1245724&r2=1245725&view=diff
==============================================================================
--- db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql (original)
+++ db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql Fri Feb 17 19:36:26 2012
@@ -258,6 +258,15 @@ commit;
 delete from a where a = 2 or a = 4 or a = 6;
 commit;
 
+-- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+
 CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 
 -- RESOLVE: missing row locks

Modified: db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql?rev=1245725&r1=1245724&r2=1245725&view=diff
==============================================================================
--- db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql (original)
+++ db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql Fri Feb 17 19:36:26 2012
@@ -244,6 +244,15 @@ commit;
 delete from a where a = 2 or a = 4 or a = 6;
 commit;
 
+-- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+
 CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault','1');
 
 -- RESOLVE: missing row locks

Modified: db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql?rev=1245725&r1=1245724&r2=1245725&view=diff
==============================================================================
--- db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql (original)
+++ db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql Fri Feb 17 19:36:26 2012
@@ -91,6 +91,15 @@ commit;
 delete from a where a = 2 or a = 4 or a = 6;
 commit;
 
+-- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+
 select a, b, c from a;
 select * from lock_table order by tabname, type desc, mode, cnt, lockname;
 commit;

Modified: db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql?rev=1245725&r1=1245724&r2=1245725&view=diff
==============================================================================
--- db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql (original)
+++ db/derby/code/branches/10.8/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql Fri Feb 17 19:36:26 2012
@@ -128,11 +128,22 @@ close scan_cursor;
 select * from lock_table order by tabname, type desc, mode, cnt, lockname;
 
 commit;
+
+-- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+
 select * from lock_table order by tabname, type desc, mode, cnt, lockname;
 commit;
 select * from a;
 commit;
 
+
 --------------------------------------------------------------------------------
 -- Test full cursor scan which does no updates, now there are committed
 -- deleted rows in the heap, make sure there are no locks on the committed
@@ -276,6 +287,16 @@ close scan_cursor;
 select * from lock_table order by tabname, type desc, mode, cnt, lockname;
 
 commit;
+
+-- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+
 select * from lock_table order by tabname, type desc, mode, cnt, lockname;
 commit;
 select * from a;
@@ -335,6 +356,16 @@ close scan_cursor;
 select * from lock_table order by tabname, type desc, mode, cnt, lockname;
 
 commit;
+
+-- The above delete and commit can allow post commit processing to run before
+-- the subsequent select is run, most likely if this run is on a table where
+-- there is one row per page.  To get reproducible results from the subsequent
+-- lock calls, wait for post commit to finish before running the select.  
+-- Without this wait "extra" locks sometimes might show up - these are locks
+-- on the committed deleted rows which have not been cleaned yet depending
+-- on timing.
+CALL WAIT_FOR_POST_COMMIT();
+
 select * from lock_table order by tabname, type desc, mode, cnt, lockname;
 commit;
 



Mime
View raw message