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 4EBF29E04 for ; Thu, 16 Feb 2012 16:13:00 +0000 (UTC) Received: (qmail 2242 invoked by uid 500); 16 Feb 2012 16:13:00 -0000 Delivered-To: apmail-db-derby-commits-archive@db.apache.org Received: (qmail 2224 invoked by uid 500); 16 Feb 2012 16:13:00 -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 2213 invoked by uid 99); 16 Feb 2012 16:13:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Feb 2012 16:13:00 +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; Thu, 16 Feb 2012 16:12:56 +0000 Received: from eris.apache.org (localhost [127.0.0.1]) by eris.apache.org (Postfix) with ESMTP id D73852388865; Thu, 16 Feb 2012 16:12:36 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r1245056 - in /db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests: master/ tests/store/ Date: Thu, 16 Feb 2012 16:12:36 -0000 To: derby-commits@db.apache.org From: mikem@apache.org X-Mailer: svnmailer-1.0.8-patched Message-Id: <20120216161236.D73852388865@eris.apache.org> Author: mikem Date: Thu Feb 16 16:12:35 2012 New Revision: 1245056 URL: http://svn.apache.org/viewvc?rev=1245056&view=rev Log: DERBY-5599 readlocks.sql fails with extra locks. 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/trunk/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql Modified: db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/readlocks.out?rev=1245056&r1=1245055&r2=1245056&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 Thu Feb 16 16:12:35 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/trunk/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out?rev=1245056&r1=1245055&r2=1245056&view=diff ============================================================================== --- db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out (original) +++ db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out Thu Feb 16 16:12:35 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/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql?rev=1245056&r1=1245055&r2=1245056&view=diff ============================================================================== --- db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql (original) +++ db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readBtreeCursorLocks.subsql Thu Feb 16 16:12:35 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/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql?rev=1245056&r1=1245055&r2=1245056&view=diff ============================================================================== --- db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql (original) +++ db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readCursorLocks.subsql Thu Feb 16 16:12:35 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/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql?rev=1245056&r1=1245055&r2=1245056&view=diff ============================================================================== --- db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql (original) +++ db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/readSetLocks.subsql Thu Feb 16 16:12:35 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/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql?rev=1245056&r1=1245055&r2=1245056&view=diff ============================================================================== --- db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql (original) +++ db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/updateholdcursorlocksJDBC30.subsql Thu Feb 16 16:12:35 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;