Derby
  1. Derby
  2. DERBY-4211

'derbyall/encryptionAll/storemats.fail:store/updatelocksJDBC30.sql' fails with unexpected locks

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.6.1.0
    • Fix Version/s: 10.5.3.1, 10.6.2.1, 10.7.1.1
    • Component/s: Test
    • Labels:
      None
    • Environment:
    • Bug behavior facts:
      Regression Test Failure

      Description

      See http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/771180-derbyall_diff.txt

                      • Diff file derbyall/encryptionAll/storemats/storemats/updatelocksJDBC30.diff
          • Start: updatelocksJDBC30 jdk1.6.0_06 storemats:storemats 2009-05-04 11:56:42 ***
            9184a9185
            > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
            9194a9196
            > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
            9205a9208
            > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
            9215a9219
            > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
            9224a9229
            > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
            Test Failed.
          • End: updatelocksJDBC30 jdk1.6.0_06 storemats:storemats 2009-05-04 11:57:00 ***

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          Duplicate of DERBY-4132?

          Show
          Knut Anders Hatlen added a comment - Duplicate of DERBY-4132 ?
          Hide
          Mike Matrigali added a comment -

          The row that shows up as extra locks is a committed deleted row. I think the problem is that this row, which in this phase of the test is the only row on the page, is usually cleaned up by the background post commit thread. Sometimes do to timing it sticks around for a few queries. If it is there, then even though it is deleted the system needs to get locks on it.

          Show
          Mike Matrigali added a comment - The row that shows up as extra locks is a committed deleted row. I think the problem is that this row, which in this phase of the test is the only row on the page, is usually cleaned up by the background post commit thread. Sometimes do to timing it sticks around for a few queries. If it is there, then even though it is deleted the system needs to get locks on it.
          Hide
          Mike Matrigali added a comment -

          this reproduced for me on a 2 processor ubuntu box running jdk 1.6, against 10.5. I've run a number of 10.5 full test runs and would estimate it passed 9 out of 10 times in this environment in full test runs.

          010-07-08 17:40:18 ***

                          • Diff file derbyall/storeall/storemats/storemats/updatelocksJDBC30.diff
              • Start: updatelocksJDBC30 jdk1.6.0_20 storemats:storemats 2010-07-08 17:33:47 ***
                9184a9185
                > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
                9194a9196
                > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
                9205a9208
                > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
                9215a9219
                > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
                9224a9229
                > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
                Test Failed.
              • End: updatelocksJDBC30 jdk1.6.0_20 storemats:storemats 2010-07-08 17:33:59 ***
                          • Diff file derbyall/storeall/storemore/backupRestore.diff
          Show
          Mike Matrigali added a comment - this reproduced for me on a 2 processor ubuntu box running jdk 1.6, against 10.5. I've run a number of 10.5 full test runs and would estimate it passed 9 out of 10 times in this environment in full test runs. 010-07-08 17:40:18 *** Diff file derbyall/storeall/storemats/storemats/updatelocksJDBC30.diff Start: updatelocksJDBC30 jdk1.6.0_20 storemats:storemats 2010-07-08 17:33:47 *** 9184a9185 > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE 9194a9196 > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE 9205a9208 > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE 9215a9219 > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE 9224a9229 > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE Test Failed. End: updatelocksJDBC30 jdk1.6.0_20 storemats:storemats 2010-07-08 17:33:59 *** Diff file derbyall/storeall/storemore/backupRestore.diff
          Hide
          Mike Matrigali added a comment -

          In 100 runs on ubuntu 2 processor jdk16 run against a SANE trunk build got 3 errors:

              • Start: updatelocksJDBC30 jdk1.6.0_20 2010-07-09 09:23:36 ***
                14308d14307
                < APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
                14309a14309
                > APP |UserTran|ROW |2 |U |A |(2,6) |GRANT|ACTIVE
                14320d14319
                < APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
                14323a14323
                > APP |UserTran|ROW |2 |U |A |(2,6) |GRANT|ACTIVE
                14334d14333
                < APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
                14339a14339
                > APP |UserTran|ROW |2 |U |A |(2,6) |GRANT|ACTIVE
                14348d14347
                < APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
                14353a14353
                > APP |UserTran|ROW |2 |U |A |(2,6) |GRANT|ACTIVE
                14361d14360
                < APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
                14366a14366
                > APP |UserTran|ROW |2 |U |A |(2,6) |GRANT|ACTIVE
                Test Failed.
              • End: updatelocksJDBC30 jdk1.6.0_20 2010-07-09 09:23:51 ***
              • Start: updatelocksJDBC30 jdk1.6.0_20 2010-07-09 09:36:58 ***
                9184a9185
                > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
                9194a9196
                > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
                9205a9208
                > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
                9215a9219
                > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
                9224a9229
                > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE
                Test Failed.
              • End: updatelocksJDBC30 jdk1.6.0_20 2010-07-09 09:37:11 ***
              • Start: updatelocksJDBC30 jdk1.6.0_20 2010-07-09 09:45:01 ***
                14338d14337
                < APP |UserTran|ROW |1 |U |A |(6,6) |GRANT|ACTIVE
                14339a14339
                > APP |UserTran|ROW |2 |U |A |(6,6) |GRANT|ACTIVE
                14352d14351
                < APP |UserTran|ROW |1 |U |A |(6,6) |GRANT|ACTIVE
                14353a14353
                > APP |UserTran|ROW |2 |U |A |(6,6) |GRANT|ACTIVE
                14365d14364
                < APP |UserTran|ROW |1 |U |A |(6,6) |GRANT|ACTIVE
                14366a14366
                > APP |UserTran|ROW |2 |U |A |(6,6) |GRANT|ACTIVE
                Test Failed.
              • End: updatelocksJDBC30 jdk1.6.0_20 2010-07-09 09:45:14 ***
          Show
          Mike Matrigali added a comment - In 100 runs on ubuntu 2 processor jdk16 run against a SANE trunk build got 3 errors: Start: updatelocksJDBC30 jdk1.6.0_20 2010-07-09 09:23:36 *** 14308d14307 < APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE 14309a14309 > APP |UserTran|ROW |2 |U |A |(2,6) |GRANT|ACTIVE 14320d14319 < APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE 14323a14323 > APP |UserTran|ROW |2 |U |A |(2,6) |GRANT|ACTIVE 14334d14333 < APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE 14339a14339 > APP |UserTran|ROW |2 |U |A |(2,6) |GRANT|ACTIVE 14348d14347 < APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE 14353a14353 > APP |UserTran|ROW |2 |U |A |(2,6) |GRANT|ACTIVE 14361d14360 < APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE 14366a14366 > APP |UserTran|ROW |2 |U |A |(2,6) |GRANT|ACTIVE Test Failed. End: updatelocksJDBC30 jdk1.6.0_20 2010-07-09 09:23:51 *** Start: updatelocksJDBC30 jdk1.6.0_20 2010-07-09 09:36:58 *** 9184a9185 > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE 9194a9196 > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE 9205a9208 > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE 9215a9219 > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE 9224a9229 > APP |UserTran|ROW |1 |U |A |(2,6) |GRANT|ACTIVE Test Failed. End: updatelocksJDBC30 jdk1.6.0_20 2010-07-09 09:37:11 *** Start: updatelocksJDBC30 jdk1.6.0_20 2010-07-09 09:45:01 *** 14338d14337 < APP |UserTran|ROW |1 |U |A |(6,6) |GRANT|ACTIVE 14339a14339 > APP |UserTran|ROW |2 |U |A |(6,6) |GRANT|ACTIVE 14352d14351 < APP |UserTran|ROW |1 |U |A |(6,6) |GRANT|ACTIVE 14353a14353 > APP |UserTran|ROW |2 |U |A |(6,6) |GRANT|ACTIVE 14365d14364 < APP |UserTran|ROW |1 |U |A |(6,6) |GRANT|ACTIVE 14366a14366 > APP |UserTran|ROW |2 |U |A |(6,6) |GRANT|ACTIVE Test Failed. End: updatelocksJDBC30 jdk1.6.0_20 2010-07-09 09:45:14 ***
          Hide
          Mike Matrigali added a comment -

          commited fix to trunk.

          m1_jdk16:41>svn commit
          Sending java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out
          Sending java/testing/org/apache/derbyTesting/functionTests/tests/store/updateBtreeHoldCursorLocksJDBC30.subsql
          Transmitting file data ..
          Committed revision 962716.

          Show
          Mike Matrigali added a comment - commited fix to trunk. m1_jdk16:41>svn commit Sending java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out Sending java/testing/org/apache/derbyTesting/functionTests/tests/store/updateBtreeHoldCursorLocksJDBC30.subsql Transmitting file data .. Committed revision 962716.
          Hide
          Mike Matrigali added a comment -

          merged fix #962716 from trunk to 10.6 codeline.

          m106_jdk16:14>svn commit
          Sending .
          Sending java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out
          Sending java/testing/org/apache/derbyTesting/functionTests/tests/store/updateBtreeHoldCursorLocksJDBC30.subsql
          Transmitting file data ..
          Committed revision 962848.

          Show
          Mike Matrigali added a comment - merged fix #962716 from trunk to 10.6 codeline. m106_jdk16:14>svn commit Sending . Sending java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out Sending java/testing/org/apache/derbyTesting/functionTests/tests/store/updateBtreeHoldCursorLocksJDBC30.subsql Transmitting file data .. Committed revision 962848.
          Hide
          Mike Matrigali added a comment -

          merged fix #962716 from trunk to 10.5 codeline.

          m105_jdk16:12>svn commit
          Sending .
          Sending java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out
          Sending java/testing/org/apache/derbyTesting/functionTests/tests/store/updateBtreeHoldCursorLocksJDBC30.subsql
          Transmitting file data ..
          Committed revision 963100.

          Show
          Mike Matrigali added a comment - merged fix #962716 from trunk to 10.5 codeline. m105_jdk16:12>svn commit Sending . Sending java/testing/org/apache/derbyTesting/functionTests/master/updatelocksJDBC30.out Sending java/testing/org/apache/derbyTesting/functionTests/tests/store/updateBtreeHoldCursorLocksJDBC30.subsql Transmitting file data .. Committed revision 963100.
          Hide
          Mike Matrigali added a comment -

          fixed, and backported to 10.5 and 10.6

          Show
          Mike Matrigali added a comment - fixed, and backported to 10.5 and 10.6
          Hide
          Mamta A. Satoor added a comment -

          Saw the failure on tinderbox with Sun's jdk 1.6 on trunk at http://dbtg.foundry.sun.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/1069761-derbyall_diff.txt

                          • Diff file derbyall/storeall/storemats/storemats/updatelocksJDBC30.diff
              • Start: updatelocksJDBC30 jdk1.6.0_18 storemats:storemats 2011-02-11 14:02:48 ***
                4983,4992d4982
                < APP |UserTran|TABLE |1 |IX |A |Tablelock |GRANT|ACTIVE
                < ij> next scan_cursor;
                < A |B |C
                < --------------------------------------------------------------------------------------------------------------------------------------------------------
                < 3 |-30 |-three
                < ij> update a set b=30,c='three' where current of scan_cursor;
                < 1 row 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
                < ---------------------------------------------------------------------------
                4993a4984,4993
                > ij> next scan_cursor;
                > A |B |C
                > --------------------------------------------------------------------------------------------------------------------------------------------------------
                > 3 |-30 |-three
                > ij> update a set b=30,c='three' where current of scan_cursor;
                > 1 row 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
                > ---------------------------------------------------------------------------
                > APP |UserTran|TABLE |3 |IX |A |Tablelock |GRANT|ACTIVE
                5003 del
                < APP |UserTran|TABLE |2 |IX |A |Tablelock |GRANT|ACTIVE
                5003a5003
                > APP |UserTran|TABLE |3 |IX |A |Tablelock |GRANT|ACTIVE
                5010 del
                < APP |UserTran|TABLE |2 |IX |A |Tablelock |GRANT|ACTIVE
                5010a5010
                > APP |UserTran|TABLE |3 |IX |A |Tablelock |GRANT|ACTIVE
                Test Failed.
              • End: updatelocksJDBC30 jdk1.6.0_18 storemats:storemats 2011-02-11 14:02:55 ***
                          • Diff file derbyall/derbynetclientmats/DerbyNetClient/encodingTests/TestEnc.diff
              • Start: TestEnc jdk1.6.0_18 DerbyNetClient derbynetclientmats:encodingTests 2011-02-11 14:08:04 ***
                derbyTesting.encoding can only be used with jdk15, skipping test
              • End: TestEnc jdk1.6.0_18 DerbyNetClient derbynetclientmats:encodingTests 2011-02-11 14:08:04 ***
                          • Diff file derbyall/encryptionAll/storemats/storemats/updatelocksJDBC30.diff
              • Start: updatelocksJDBC30 jdk1.6.0_18 storemats:storemats 2011-02-11 14:11:15 ***
                2504,2513d2503
                < APP |UserTran|TABLE |1 |IX |A |Tablelock |GRANT|ACTIVE
                < ij> next scan_cursor;
                < A |B |C
                < --------------------------------------------------------------------------------------------------------------------------------------------------------
                < 3 |-30 |-three
                < ij> update a set b=30,c='three' where current of scan_cursor;
                < 1 row 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
                < ---------------------------------------------------------------------------
                2514a2505,2514
                > ij> next scan_cursor;
                > A |B |C
                > --------------------------------------------------------------------------------------------------------------------------------------------------------
                > 3 |-30 |-three
                > ij> update a set b=30,c='three' where current of scan_cursor;
                > 1 row 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
                > ---------------------------------------------------------------------------
                > APP |UserTran|TABLE |3 |IX |A |Tablelock |GRANT|ACTIVE
                2524 del
                < APP |UserTran|TABLE |2 |IX |A |Tablelock |GRANT|ACTIVE
                2524a2524
                > APP |UserTran|TABLE |3 |IX |A |Tablelock |GRANT|ACTIVE
                2531 del
                < APP |UserTran|TABLE |2 |IX |A |Tablelock |GRANT|ACTIVE
                2531a2531
                > APP |UserTran|TABLE |3 |IX |A |Tablelock |GRANT|ACTIVE
                Test Failed.
              • End: updatelocksJDBC30 jdk1.6.0_18 storemats:storemats 2011-02-11 14:11:23 ***
          Show
          Mamta A. Satoor added a comment - Saw the failure on tinderbox with Sun's jdk 1.6 on trunk at http://dbtg.foundry.sun.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/1069761-derbyall_diff.txt Diff file derbyall/storeall/storemats/storemats/updatelocksJDBC30.diff Start: updatelocksJDBC30 jdk1.6.0_18 storemats:storemats 2011-02-11 14:02:48 *** 4983,4992d4982 < APP |UserTran|TABLE |1 |IX |A |Tablelock |GRANT|ACTIVE < ij> next scan_cursor; < A |B |C < -------------------------------------------------------------------------------------------------------------------------------------------------------- < 3 |-30 |-three < ij> update a set b=30,c='three' where current of scan_cursor; < 1 row 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 < --------------------------------------------------------------------------- 4993a4984,4993 > ij> next scan_cursor; > A |B |C > -------------------------------------------------------------------------------------------------------------------------------------------------------- > 3 |-30 |-three > ij> update a set b=30,c='three' where current of scan_cursor; > 1 row 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 > --------------------------------------------------------------------------- > APP |UserTran|TABLE |3 |IX |A |Tablelock |GRANT|ACTIVE 5003 del < APP |UserTran|TABLE |2 |IX |A |Tablelock |GRANT|ACTIVE 5003a5003 > APP |UserTran|TABLE |3 |IX |A |Tablelock |GRANT|ACTIVE 5010 del < APP |UserTran|TABLE |2 |IX |A |Tablelock |GRANT|ACTIVE 5010a5010 > APP |UserTran|TABLE |3 |IX |A |Tablelock |GRANT|ACTIVE Test Failed. End: updatelocksJDBC30 jdk1.6.0_18 storemats:storemats 2011-02-11 14:02:55 *** Diff file derbyall/derbynetclientmats/DerbyNetClient/encodingTests/TestEnc.diff Start: TestEnc jdk1.6.0_18 DerbyNetClient derbynetclientmats:encodingTests 2011-02-11 14:08:04 *** derbyTesting.encoding can only be used with jdk15, skipping test End: TestEnc jdk1.6.0_18 DerbyNetClient derbynetclientmats:encodingTests 2011-02-11 14:08:04 *** Diff file derbyall/encryptionAll/storemats/storemats/updatelocksJDBC30.diff Start: updatelocksJDBC30 jdk1.6.0_18 storemats:storemats 2011-02-11 14:11:15 *** 2504,2513d2503 < APP |UserTran|TABLE |1 |IX |A |Tablelock |GRANT|ACTIVE < ij> next scan_cursor; < A |B |C < -------------------------------------------------------------------------------------------------------------------------------------------------------- < 3 |-30 |-three < ij> update a set b=30,c='three' where current of scan_cursor; < 1 row 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 < --------------------------------------------------------------------------- 2514a2505,2514 > ij> next scan_cursor; > A |B |C > -------------------------------------------------------------------------------------------------------------------------------------------------------- > 3 |-30 |-three > ij> update a set b=30,c='three' where current of scan_cursor; > 1 row 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 > --------------------------------------------------------------------------- > APP |UserTran|TABLE |3 |IX |A |Tablelock |GRANT|ACTIVE 2524 del < APP |UserTran|TABLE |2 |IX |A |Tablelock |GRANT|ACTIVE 2524a2524 > APP |UserTran|TABLE |3 |IX |A |Tablelock |GRANT|ACTIVE 2531 del < APP |UserTran|TABLE |2 |IX |A |Tablelock |GRANT|ACTIVE 2531a2531 > APP |UserTran|TABLE |3 |IX |A |Tablelock |GRANT|ACTIVE Test Failed. End: updatelocksJDBC30 jdk1.6.0_18 storemats:storemats 2011-02-11 14:11:23 ***
          Hide
          Mike Matrigali added a comment -

          My first guess is this test is being affected by the istats change. I would be happy to fix the test, but first want to make sure
          there is not an istats bug that I would be hiding. So would like some feed back on the following:

          1) Are the locks that are requested in background gotten on a "user" transaction, rather than an internal transaction? If so, should
          they be? Current the background daemon uses internal transactions so that user's querying the lock table can tell the difference between
          their xact's and internal work.

          2) I see from the derby.log that istats work is definitely happening. Should istats be working on these tables. The tables in this test always about
          7 rows. From reading the ones created in the updatelocks test are always created using the following form:
          create table a(a int, b int);
          alter table a add column c varchar(1900);
          insert into a values (1, 10, 'one');
          insert into a values (2, 20, 'two');
          insert into a values (3, 30, 'three');
          insert into a values (4, 40, 'four');
          insert into a values (5, 50, 'five');
          insert into a values (6, 60, 'six');
          insert into a values (7, 70, 'seven');
          create index a_idx on a (a);
          commit;

          Some have indexes, some don't. If they have indexes they are always created after the row are loaded so all stats should be up to date.

          Show
          Mike Matrigali added a comment - My first guess is this test is being affected by the istats change. I would be happy to fix the test, but first want to make sure there is not an istats bug that I would be hiding. So would like some feed back on the following: 1) Are the locks that are requested in background gotten on a "user" transaction, rather than an internal transaction? If so, should they be? Current the background daemon uses internal transactions so that user's querying the lock table can tell the difference between their xact's and internal work. 2) I see from the derby.log that istats work is definitely happening. Should istats be working on these tables. The tables in this test always about 7 rows. From reading the ones created in the updatelocks test are always created using the following form: create table a(a int, b int); alter table a add column c varchar(1900); insert into a values (1, 10, 'one'); insert into a values (2, 20, 'two'); insert into a values (3, 30, 'three'); insert into a values (4, 40, 'four'); insert into a values (5, 50, 'five'); insert into a values (6, 60, 'six'); insert into a values (7, 70, 'seven'); create index a_idx on a (a); commit; Some have indexes, some don't. If they have indexes they are always created after the row are loaded so all stats should be up to date.
          Hide
          Kristian Waagan added a comment -

          Running store/updatelocksJDBC30.sql with istat logging indicates that no istat work is being done:
          Thu May 26 12:10:53 CEST 2011 Thread[main,5,main]

          {istat}

          stopping daemon, active=false, work/age=0/8338 [q/p/s=0/0/0,err:k/u/c=0/0/0,rej:f/d/o=0/0/0]

          There have been reports of failures for these tests long before the istat feature was available. Even though the initial addition of the istat feature caused failures for at least some of the updatelocks tests, this doesn't appear to be the case any more.

          One theory is that some times locks are taken due to activity in a background thread. Would rewriting the tests to JUnit and adding wait/retry logic wrt querying the lock table be a way forward?
          A quick look at the existing test classes suggests that this is a fair amount of work, but the tests seem to rely on a rather smallish set of core functions.

          Show
          Kristian Waagan added a comment - Running store/updatelocksJDBC30.sql with istat logging indicates that no istat work is being done: Thu May 26 12:10:53 CEST 2011 Thread [main,5,main] {istat} stopping daemon, active=false, work/age=0/8338 [q/p/s=0/0/0,err:k/u/c=0/0/0,rej:f/d/o=0/0/0] There have been reports of failures for these tests long before the istat feature was available. Even though the initial addition of the istat feature caused failures for at least some of the updatelocks tests, this doesn't appear to be the case any more. One theory is that some times locks are taken due to activity in a background thread. Would rewriting the tests to JUnit and adding wait/retry logic wrt querying the lock table be a way forward? A quick look at the existing test classes suggests that this is a fair amount of work, but the tests seem to rely on a rather smallish set of core functions.
          Hide
          Dag H. Wanvik added a comment -

          I tried to run ijToJUnit on the master, but it choked on the use of cursors in the test, so you'd need to fix the tool if you want to attempt automatic conversion of (parts) of the test to JUnit.

          Show
          Dag H. Wanvik added a comment - I tried to run ijToJUnit on the master, but it choked on the use of cursors in the test, so you'd need to fix the tool if you want to attempt automatic conversion of (parts) of the test to JUnit.
          Hide
          Knut Anders Hatlen added a comment -

          [bulk update] Close all resolved issues that haven't been updated for more than one year.

          Show
          Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.

            People

            • Assignee:
              Mike Matrigali
              Reporter:
              Ole Solberg
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development