db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2156) message XSDB8 and 42Y32 have references to db2j
Date Fri, 30 Apr 2010 09:52:54 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862612#action_12862612
] 

Knut Anders Hatlen commented on DERBY-2156:
-------------------------------------------

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.

> message XSDB8 and 42Y32 have references to db2j
> -----------------------------------------------
>
>                 Key: DERBY-2156
>                 URL: https://issues.apache.org/jira/browse/DERBY-2156
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL, Store
>    Affects Versions: 10.1.3.1, 10.2.1.6
>            Reporter: Myrna van Lunteren
>            Priority: Trivial
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message