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 2006/02/08 01:59:27 UTC
svn commit: r375818 - in
/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests:
master/readlocks.out tests/store/readBtreeSetLocks.subsql
Author: mikem
Date: Tue Feb 7 16:59:25 2006
New Revision: 375818
URL: http://svn.apache.org/viewcvs?rev=375818&view=rev
Log:
DERBY-861
issue is that just prior to this query the test deletes and commits some rows. In one phase of this locking test
the table is configured to have one row per page. In this case as soon as the delete commits, the post commit background
thread can be scheduled to reclaim the deleted rows. This scheduling is completely at the discretion of a number of factors including: OS/JVM/processor availbility . To get reproducible results for this query I added a wait after the delete.
Modified:
db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out
db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeSetLocks.subsql
Modified: db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out
URL: http://svn.apache.org/viewcvs/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out?rev=375818&r1=375817&r2=375818&view=diff
==============================================================================
--- db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out (original)
+++ db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out Tue Feb 7 16:59:25 2006
@@ -2840,6 +2840,15 @@
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 from a;
A
-----------
@@ -3065,6 +3074,15 @@
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 from a;
A
-----------
@@ -5931,6 +5949,15 @@
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 from a;
A
-----------
@@ -6159,6 +6186,15 @@
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 from a;
A
-----------
@@ -9090,6 +9126,15 @@
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 from a;
A
-----------
@@ -9315,6 +9360,15 @@
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 from a;
A
-----------
@@ -12219,6 +12273,15 @@
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 from a;
A
-----------
@@ -12447,6 +12510,15 @@
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 from a;
A
-----------
@@ -15865,6 +15937,15 @@
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 from a;
A
-----------
@@ -16108,6 +16189,15 @@
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 from a;
A
-----------
@@ -19518,6 +19608,15 @@
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 from a;
A
-----------
@@ -19764,6 +19863,15 @@
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 from a;
A
-----------
@@ -22717,6 +22825,15 @@
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 from a;
A
-----------
@@ -22952,6 +23069,15 @@
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 from a;
A
-----------
@@ -25893,6 +26019,15 @@
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 from a;
A
-----------
@@ -26132,6 +26267,15 @@
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 from a;
A
-----------
Modified: db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeSetLocks.subsql
URL: http://svn.apache.org/viewcvs/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeSetLocks.subsql?rev=375818&r1=375817&r2=375818&view=diff
==============================================================================
--- db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeSetLocks.subsql (original)
+++ db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeSetLocks.subsql Tue Feb 7 16:59:25 2006
@@ -74,6 +74,15 @@
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 from a;
select * from lock_table order by tabname, type desc, mode, cnt, lockname;
commit;