Return-Path: X-Original-To: apmail-db-derby-commits-archive@www.apache.org Delivered-To: apmail-db-derby-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A0EB89521 for ; Sun, 19 Feb 2012 22:26:07 +0000 (UTC) Received: (qmail 53964 invoked by uid 500); 19 Feb 2012 22:26:07 -0000 Delivered-To: apmail-db-derby-commits-archive@db.apache.org Received: (qmail 53938 invoked by uid 500); 19 Feb 2012 22:26:07 -0000 Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: "Derby Development" List-Id: Delivered-To: mailing list derby-commits@db.apache.org Received: (qmail 53930 invoked by uid 99); 19 Feb 2012 22:26:07 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Feb 2012 22:26:07 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Feb 2012 22:26:04 +0000 Received: from eris.apache.org (localhost [127.0.0.1]) by eris.apache.org (Postfix) with ESMTP id 6AED72388C2A; Sun, 19 Feb 2012 22:25:44 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r1291076 - in /db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests: master/ tests/store/ Date: Sun, 19 Feb 2012 22:25:43 -0000 To: derby-commits@db.apache.org From: mikem@apache.org X-Mailer: svnmailer-1.0.8-patched Message-Id: <20120219222544.6AED72388C2A@eris.apache.org> Author: mikem Date: Sun Feb 19 22:25:43 2012 New Revision: 1291076 URL: http://svn.apache.org/viewvc?rev=1291076&view=rev Log: DERBY-5599 readlocks.sql fails with extra locks. backported #1245056 from trunk to 10.7 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.7/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql Modified: db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out?rev=1291076&r1=1291075&r2=1291076&view=diff ============================================================================== --- db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out (original) +++ db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out Sun Feb 19 22:25:43 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.7/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out?rev=1291076&r1=1291075&r2=1291076&view=diff ============================================================================== --- db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out (original) +++ db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out Sun Feb 19 22:25:43 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.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql?rev=1291076&r1=1291075&r2=1291076&view=diff ============================================================================== --- db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql (original) +++ db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql Sun Feb 19 22:25:43 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.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql?rev=1291076&r1=1291075&r2=1291076&view=diff ============================================================================== --- db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql (original) +++ db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql Sun Feb 19 22:25:43 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.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql?rev=1291076&r1=1291075&r2=1291076&view=diff ============================================================================== --- db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql (original) +++ db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql Sun Feb 19 22:25:43 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.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql?rev=1291076&r1=1291075&r2=1291076&view=diff ============================================================================== --- db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql (original) +++ db/derby/code/branches/10.7/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql Sun Feb 19 22:25:43 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;