Derby
  1. Derby
  2. DERBY-2156

message XSDB8 and 42Y32 have references to db2j

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 10.1.3.1, 10.2.1.6
    • Fix Version/s: 10.7.1.1
    • Component/s: SQL, Store
    • Labels:
      None
    • Urgency:
      Normal
    • Issue & fix info:
      Newcomer

      Description

      trunk/messages.xml shows two messages that incorrectly refer to db2j:

      42Y32=Aggregator class ''

      {0}'' for aggregate ''{1}'' on type {2} does not implement com.ibm.db2j.aggregates.Aggregator.
      There is now no class Aggregator in Derby. This message is generated from the class:
      org.apache.derby.impl.sql.compile.AggregateNode.java.
      private void checkAggregatorClassName(String className) throws StandardException
      {
      className = verifyClassExist(className, false);
      if (!classInspector.assignableTo(className, "org.apache.derby.iapi.sql.execute.ExecAggregator"))
      { throw StandardException.newException (SQLState.LANG_BAD_AGGREGATOR_CLASS2, className, aggregateName, operand.getTypeId().getSQLTypeName()); }
      }

      The original in Cloudscape had a reference to an Aggregator class, the if looked like this:

      if (!classInspector.assignableTo(className, "com.ibm.db2j.aggregates.Aggregator") &&
      !classInspector.assignableTo
      (className, "com.ibm.db2j.protocol.Database.Language.Execution.ExecAggregator"))
      {
      throw StandardException.newException(SQLState.LANG_BAD_AGGREGATOR_CLASS2,
      ....

      Maybe the message now needs to mention org.apache.derby.iapi.sql.execute.ExecAggregator?
      But, I think maybe this message cannot be obtained unless someone introduces a bug within the Derby code. I think the reference to another internal class should be removed. Or maybe the text of Cloudscape message 42Y31 can be used: 42Y31=LANG_BAD_AGGREGATOR_CLASS="Aggregator class ''{0}

      '' for aggregate ''

      {1}'' on type {2} is inaccessable or does not exist."

      XSDB8.D=DATA_MULTIPLE_JBMS_FORCE_LOCK ="WARNING: Derby (instance {0}) is attempting to boot the database {1}

      even though Derby (instance

      {2}

      ) may still be active. Only one instance of Derby should boot a database at a time. Severe and non-recoverable corruption can result if 2 instances of Derby boot on the same database at the same time. The db2j.database.forceDatabaseLock=true property has been set, so the database will not boot until the db.lck is no longer present. Normally this file is removed when the first instance of Derby to boot on the database exits, but it may be left behind in some shutdowns. It will be necessary to remove the file by hand in that case. It is important to verify that no other VM is accessing the database before deleting the db.lck file by hand."

      John Embretsen commented on this in DERBY-1838:
      https://issues.apache.org/jira/browse/DERBY-1838#action_12434090

      Indicating that not only should the message refer to derby.database.forceDatabaseLock, but the replacement of parameters is not happening either.
      But I can not find a place where this message is generated, so maybe it can just be removed.

      1. forceDatabaseLock.diff
        58 kB
        Knut Anders Hatlen

        Activity

        Myrna van Lunteren created issue -
        Mike Matrigali made changes -
        Field Original Value New Value
        Component/s SQL [ 11408 ]
        Component/s Store [ 11412 ]
        Kathey Marsden made changes -
        Component/s Newcomer [ 12310640 ]
        Dag H. Wanvik made changes -
        Derby Categories [Newcomer]
        Dag H. Wanvik made changes -
        Component/s Newcomer [ 12310640 ]
        Dag H. Wanvik made changes -
        Issue & fix info [Newcomer]
        Hide
        Knut Anders Hatlen added a comment -

        Triaged for 10.5.2. 42Y32 was fixed in DERBY-2676, but the problem is still there for XSDB8.D.

        Show
        Knut Anders Hatlen added a comment - Triaged for 10.5.2. 42Y32 was fixed in DERBY-2676 , but the problem is still there for XSDB8.D.
        Knut Anders Hatlen made changes -
        Urgency Normal
        Hide
        Knut Anders Hatlen added a comment -

        I don't see the problems with replacement of parameters that John saw. Here's the message I get when I run with derby.database.forceDatabaseLock=true on phoneME Advanced:

        ERROR XSDB8: WARNING: Derby (instance c013800d-0128-4e11-256e-000000122fa8) is attempting to boot the database /home/kah/derby/test/db even though Derby (instance c013800d-0128-4e10-fe16-000000123704) may still be active. Only one instance of Derby should boot a database at a time. Severe and non-recoverable corruption can result if 2 instances of Derby boot on the same database at the same time. The db2j.database.forceDatabaseLock=true property has been set, so the database will not boot until the db.lck is no longer present. Normally this file is removed when the first instance of Derby to boot on the database exits, but it may be left behind in some shutdowns. It will be necessary to remove the file by hand in that case. It is important to verify that no other VM is accessing the database before deleting the db.lck file by hand.

        The problem John saw on Java 1.3.1 looked like if the JVM chose to invoke StandardException.newException(String,Object) instead of StandardException.newException(String,Object[]). Perhaps a JVM bug.

        Show
        Knut Anders Hatlen added a comment - I don't see the problems with replacement of parameters that John saw. Here's the message I get when I run with derby.database.forceDatabaseLock=true on phoneME Advanced: ERROR XSDB8: WARNING: Derby (instance c013800d-0128-4e11-256e-000000122fa8) is attempting to boot the database /home/kah/derby/test/db even though Derby (instance c013800d-0128-4e10-fe16-000000123704) may still be active. Only one instance of Derby should boot a database at a time. Severe and non-recoverable corruption can result if 2 instances of Derby boot on the same database at the same time. The db2j.database.forceDatabaseLock=true property has been set, so the database will not boot until the db.lck is no longer present. Normally this file is removed when the first instance of Derby to boot on the database exits, but it may be left behind in some shutdowns. It will be necessary to remove the file by hand in that case. It is important to verify that no other VM is accessing the database before deleting the db.lck file by hand. The problem John saw on Java 1.3.1 looked like if the JVM chose to invoke StandardException.newException(String,Object) instead of StandardException.newException(String,Object[]). Perhaps a JVM bug.
        Hide
        Knut Anders Hatlen added a comment -

        The attached patch replaces db2j.database.forceDatabaseLock with derby.database.forceDatabaseLock in all the message files and in ErrorCodeTest. Running the regression tests now.

        Show
        Knut Anders Hatlen added a comment - The attached patch replaces db2j.database.forceDatabaseLock with derby.database.forceDatabaseLock in all the message files and in ErrorCodeTest. Running the regression tests now.
        Knut Anders Hatlen made changes -
        Attachment forceDatabaseLock.diff [ 12443278 ]
        Knut Anders Hatlen made changes -
        Assignee Knut Anders Hatlen [ knutanders ]
        Issue & fix info [Newcomer] [Newcomer, Patch Available]
        Knut Anders Hatlen made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Hide
        Knut Anders Hatlen added a comment -

        Committed revision 939730.

        Show
        Knut Anders Hatlen added a comment - Committed revision 939730.
        Knut Anders Hatlen made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Issue & fix info [Newcomer, Patch Available] [Newcomer]
        Fix Version/s 10.7.0.0 [ 12314971 ]
        Resolution Fixed [ 1 ]
        Rick Hillegas made changes -
        Fix Version/s 10.7.1.1 [ 12315564 ]
        Fix Version/s 10.7.1.0 [ 12314971 ]
        Myrna van Lunteren made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Gavin made changes -
        Workflow jira [ 12391692 ] Default workflow, editable Closed status [ 12800719 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open In Progress In Progress
        1240d 17h 16m 1 Knut Anders Hatlen 30/Apr/10 11:18
        In Progress In Progress Resolved Resolved
        5h 59m 1 Knut Anders Hatlen 30/Apr/10 17:18
        Resolved Resolved Closed Closed
        258d 5h 30m 1 Myrna van Lunteren 13/Jan/11 21:48

          People

          • Assignee:
            Knut Anders Hatlen
            Reporter:
            Myrna van Lunteren
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development