[
https://issues.apache.org/jira/browse/DERBY-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-3302:
----------------------------------
Could you comment on the SQLChar case, ie. the non collation recovery path. In
that case is there something that
guarantees at recovery time that localeFinder won't be null and we will never
enter the code for the database
context?:
protected LocaleFinder getLocaleFinder()
{
// This is not very satisfactory, as it creates a dependency on
// the DatabaseContext. It's the best I could do on short notice,
// though. - Jeff
if (localeFinder == null)
{
DatabaseContext dc = (DatabaseContext) ContextService.getContext(Dat
baseContext.CONTEXT_ID);
if( dc != null)
localeFinder = dc.getDatabase();
}
return localeFinder;
}
> NullPointerException during recovery of database with territory-based
> collation
> -------------------------------------------------------------------------------
>
> Key: DERBY-3302
> URL: https://issues.apache.org/jira/browse/DERBY-3302
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Mamta A. Satoor
> Priority: Critical
> Fix For: 10.4.0.0
>
> Attachments: npe.sql
>
>
> When logical undo is performed on a database with territory-based collation,
> you may get a NullPointerException in SQLChar.getCollationKey() because
> SQLChar.getLocaleFinder() returns null.
> This bug was reported on derby-user:
> http://thread.gmane.org/gmane.comp.apache.db.derby.user/8253
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
