svn commit: r348213 - /db/derby/code/branches/10.0/java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactory.java

[mi...@apache.org]

Author: mikem
Date: Tue Nov 22 11:00:06 2005
New Revision: 348213

URL: http://svn.apache.org/viewcvs?rev=348213&view=rev
Log:
DERBY-662 porting patch from trunk into 10.0 line.

Sometimes during redo the system will incorrectly remove the file associated
with a table. The bug requires the following conditions to reproduce:
1) The OS/filesystem must be case insensitive such that a request to delete
a file named C2080.dat would also remove c2080.dat. This is true in
windows default file systems, not true in unix/linux filesystems that
I am aware of.
2) The system must be shutdown not in a clean manner, such that a subsequent
access of the database causes a REDO recovery action of a drop table
statement. This means that a drop table statement must have happened
since the last checkpoint in the log file. Examples of things that cause
checkpoints are:
o clean shutdown from ij using the "exit" command
o clean shutdown of database using the "shutdown=true" url
o calling the checkpoint system procedure
o generating enough log activity to cause a regularly scheduled checkpoint.
3) If the conglomerate number of the above described drop table is TABLE_1,
then for a problem to occur there must also exist in the database a table
such that it's HEX(TABLE_2) = TABLE_1
4) Either TABLE_2 must not be accessed during REDO prior to the REDO operation
of the drop of TABLE_1 or there must be enough other table references during
the REDO phase to push the caching of of the open of TABLE_2 out of cache.

If all of the above conditions are met then during REDO the system will
incorrectly delete TABLE_2 while trying to redo the drop of TABLE_1.
<p>
I will be adding the following test to reproduce the problem:
1) create 500 tables, need enough tables to insure that conglomerate number
2080 (c820.dat) and 8320 (c2080.dat) exist.
2) checkpoint the database so that create does not happen during REDO
3) drop table with conglomerate number 2080, mapping to c820.dat. It looks
it up in the catalog in case conglomerate number assignment changes for
some reason.
4) exit the database without a clean shudown, this is the default for test
suites which run multiple tests in a single db - no clean shutdown is done.
Since we only do a single drop since the last checkpoint, test will cause
the drop during the subsequent REDO.
5) run next test program dropcrash2, which will cause redo of the drop. At
this point the bug will cause file c2080.dat to be incorrectly deleted and
thus accesses to conglomerate 8320 will throw container does not exist
errors.
6) check the consistency of the database which will find the container does
not exist error.


Modified:
    db/derby/code/branches/10.0/java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactory.java

Modified: db/derby/code/branches/10.0/java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactory.java
URL: http://svn.apache.org/viewcvs/db/derby/code/branches/10.0/java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactory.java?rev=348213&r1=348212&r2=348213&view=diff
==============================================================================
--- db/derby/code/branches/10.0/java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactory.java (original)
+++ db/derby/code/branches/10.0/java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactory.java Tue Nov 22 11:00:06 2005
@@ -2227,7 +2227,7 @@
             else
             {
                 sb.append(stub ? 'D' : 'C');
-                sb.append(containerId.getContainerId());
+                sb.append(Long.toHexString(containerId.getContainerId()));
                 sb.append(".DAT");
             }
             return storageFactory.newStorageFile( sb.toString());