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.
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
DERBY-3302 The user was running into null pointer exception at the time of database recovery
because Derby was trying to get the Collator object through database context. But the
Collator object is already available in the territory sensitive character classes and we
do not have to go to database context to get it. I changed the code to use that collator
object rather than look into database context. The reason for null pointer exception was
that database context was not loaded yet during database recovery.
Adding a test case for DERBY-3302. There are two sub-test case classes involved here,
col_rec1.java and col_rec2.java
The purpose of col_rec1 test and col_rec2 test is to create a territory based database and
create some objects with collation sensitive character types. Then, make the database crash
so that during the recovery, store engine has to do collation related operations. Those
collation related operations are going to require that we use correct Collator object. DERBY-3302 demonstrated a npe during this operation because Derby was relying on database
context to get the correct Collator object. But database context is not available at this
point in the recovery. With the fix for DERBY-3302, the Collator object will now be
obtained from collation sensitive datatypes itself rather than looking at database context
which is not available at this point in recovery.
col_rec1 class will do the steps of create a territory based database and create some
objects with collation sensitive character types. Then, make the database crash.
col_rec2 class will do the part of rebooting the crashed db which will require store to go
through recovery.
Merging changes 610846 from trunk into 10.3 codeline. This is for DERBY-3302. Commit comments
for trunk 610846 were as follows
DERBY-3302 The user was running into null pointer exception at the time of database recovery
because Derby was trying to get the Collator object through database context. But the
Collator object is already available in the territory sensitive character classes and we
do not have to go to database context to get it. I changed the code to use that collator
object rather than look into database context. The reason for null pointer exception was
that database context was not loaded yet during database recovery.
Mergeing test changes from trunk revision(611295) into 10.3 codeline. The commit coments
in trunk were as follows
Adding a test case for DERBY-3302. There are two sub-test case classes involved here, col_rec1.java and col_rec2.java
The purpose of col_rec1 test and col_rec2 test is to create a territory based database and create some objects with collation sensitive character types. Then, make the database crash so that during the recovery, store engine has to do collation related operations. Those collation related operations are going to require that we use correct Collator object. DERBY-3302 demonstrated a npe during this operation because Derby was relying on database context to get the correct Collator object. But database context is not available at this point in the recovery. With the fix for DERBY-3302, the Collator object will now be obtained from collation sensitive datatypes itself rather than looking at database context which is not available at this point in recovery.
col_rec1 class will do the steps of create a territory based database and create some objects with collation sensitive character types. Then, make the database crash. col_rec2 class will do the part of rebooting the crashed db which will require store to go through recovery.
Bug
Closed
Critical
NullPointerException during recovery of database with territory-based collation
