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 2012/02/20 02:31:45 UTC
svn commit: r1291113 - in
/db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests:
master/ tests/store/
Author: mikem
Date: Mon Feb 20 01:31:44 2012
New Revision: 1291113
URL: http://svn.apache.org/viewvc?rev=1291113&view=rev
Log:
DERBY-5599 readlocks.sql fails with extra locks.
backported #1245056 from trunk to 10.6 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.6/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out
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/readBtreeCursorLocks.subsql
db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql
db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql
db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql
Modified: db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out?rev=1291113&r1=1291112&r2=1291113&view=diff
==============================================================================
--- db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out (original)
+++ db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out Mon Feb 20 01:31:44 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.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=1291113&r1=1291112&r2=1291113&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 Mon Feb 20 01:31:44 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.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql?rev=1291113&r1=1291112&r2=1291113&view=diff
==============================================================================
--- db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql (original)
+++ db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql Mon Feb 20 01:31:44 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.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql?rev=1291113&r1=1291112&r2=1291113&view=diff
==============================================================================
--- db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql (original)
+++ db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql Mon Feb 20 01:31:44 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.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql?rev=1291113&r1=1291112&r2=1291113&view=diff
==============================================================================
--- db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql (original)
+++ db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql Mon Feb 20 01:31:44 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.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql?rev=1291113&r1=1291112&r2=1291113&view=diff
==============================================================================
--- db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql (original)
+++ db/derby/code/branches/10.6/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql Mon Feb 20 01:31:44 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;