db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5232) Put a stern README file in log and seg0 directories to warn users of corrpution they will cause if they touch files there
Date Wed, 24 Oct 2012 15:56:14 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mamta A. Satoor updated DERBY-5232:
-----------------------------------

    Attachment: DERBY5232_patch3_stat.txt
                DERBY5232_patch3_diff.txt

Another updated patch. It is NOT ready for commit and has indentation issues and can use more
comments but I wanted to share couple changes made in this patch compared to the last one.

1)I talked to Mike offline about getting hold of storagefactory in the "access" code in order
to create readme file in the seg0 directory. Mike suggested that we create a new method(say
createDataWarningFile) in RawStoreFactory.java interface to create a readme file. RawStore
implements this interface and it will create the readme file using storagefactory. RAMAccessManager
can then call rawstore.createDataWarningFile to create the readme file in seg0 directory

2)To address the code duplication brought up by Knut, 
I agree with that and was planning on doing something about it. Currently, we create 3 readme
files and the code to do is pretty much the same other than the directory path and message
id used to load the content into the newly created file. I thought of adding a new method
to StorageFactory.java interface, where a new file will be created in the passed directory
and the new file will get data written into it passed as a parameter to the new method. The
new method would look as follows
    public StorageFile newStorageFile( String directoryName,
               String fileName,
               String fileContent);
But the problem with this approach is that StorageFactory interface gets implemented by 5
classes and hence I am having to put the method implementation in all those 5 classes. I think
rather than putting the burden on StorageFactory implementor to implement this new method,
we should continue to have the code duplication, since that code is not too big. I am open
to suggestions on this one, though. The new patch attached shows the new method in StorageFactory
and it's implementation by 5 different classes.

3)Also, I think the try catch finally code for creating the new file and loading data into
it can be simplified to following. Let me know if I am missing something in this code optimization
Code in the newly attached patch is as follows
+               StorageRandomAccessFile randomAccessFile=null;
+               try {
+                       randomAccessFile = sf.getRandomAccessFile("rw");
+                       randomAccessFile.writeChars(fileContent);
+               }
+        catch (IOException ioe)
+        {
+            try
+            {
+                if (randomAccessFile != null)
+                       randomAccessFile.close();
+            }
+            catch (IOException ioe2)
+            {
+               randomAccessFile = null;
+            }
+        }
+        finally
+        {
+            try
+            {
+                if (randomAccessFile != null)
+                       randomAccessFile.close();
+            }
+            catch (IOException ioe)
+            {
+                // Ignore exception on close
+               randomAccessFile = null;
+            }
+        }
+               return sf;

Instead, we can write it as follows
Another updated patch. It is NOT ready for commit and has indentation issues and can use more
comments but I wanted to share couple changes made in this patch compared to the last one.

1)I talked to Mike offline about getting hold of storagefactory in the "access" code in order
to create readme file in the seg0 directory. Mike suggested that we create a new method(say
createDataWarningFile) in RawStoreFactory.java interface to create a readme file. RawStore
implements this interface and it will create the readme file using storagefactory. RAMAccessManager
can then call rawstore.createDataWarningFile to create the readme file in seg0 directory

2)To address the code duplication brought up by Knut, 
I agree with that and was planning on doing something about it. Currently, we create 3 readme
files and the code to do is pretty much the same other than the directory path and message
id used to load the content into the newly created file. I thought of adding a new method
to StorageFactory.java interface, where a new file will be created in the passed directory
and the new file will get data written into it passed as a parameter to the new method. The
new method would look as follows
    public StorageFile newStorageFile( String directoryName,
               String fileName,
               String fileContent);
But the problem with this approach is that StorageFactory interface gets implemented by 5
classes and hence I am having to put the method implementation in all those 5 classes. I think
rather than putting the burden on StorageFactory implementor to implement this new method,
we should continue to have the code duplication, since that code is not too big. I am open
to suggestions on this one, though. The new patch attached shows the new method in StorageFactory
and it's implementation by 5 different classes.

3)Also, I think the try catch finally code for creating the new file and loading data into
it can be simplified to following. Let me know if I am missing something in this code optimization
Code in the newly attached patch is as follows
+               StorageRandomAccessFile randomAccessFile=null;
+               try {
+                       randomAccessFile = sf.getRandomAccessFile("rw");
+                       randomAccessFile.writeChars(fileContent);
+               }
+        catch (IOException ioe)
+        {
+        }
+        finally
+        {
+            try
+            {
+                if (randomAccessFile != null)
+                       randomAccessFile.close();
+            }
+            catch (IOException ioe)
+            {
+                // Ignore exception on close
+               randomAccessFile = null;
+            }
+        }
+               return sf;

Basically, I have removed the code from inside the catch block since finally does the exact
same thing.

As always, appreciate any feedback on the patch. Thanks.
                
> Put a stern README file in log and seg0 directories to warn users of corrpution they
will cause if they touch files there
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5232
>                 URL: https://issues.apache.org/jira/browse/DERBY-5232
>             Project: Derby
>          Issue Type: Improvement
>          Components: Store
>    Affects Versions: 10.8.1.2
>            Reporter: Kathey Marsden
>            Assignee: Mamta A. Satoor
>         Attachments: DERBY5232_patch1_diff.txt, DERBY5232_patch1_stat.txt, DERBY5232_patch2_diff.txt,
DERBY5232_patch2_stat.txt, DERBY5232_patch3_diff.txt, DERBY5232_patch3_stat.txt
>
>
> Users often on bad advice or desperation  touch or delete files in the log or seg0 directories
(mostly log).
> I think it would be good for new databases and on upgrade that a file be created in these
directories with a name like:
> TOUCHING_FILES_HERE_WILL_CORRUPT_DB_README.txt
> or some such to warn of the perils of doing this and the corrupting effects and how it
can eliminate any possibility of salvage. It should also encourage users to make a zip backup
of the database directory with no jvm currently accessing it before trying to do anything
with the database if it appears to be already corrupt.  Also point to backup/restore documentation
and encourage restore of a good backup into an empty directory if the database is corrupt.
> I'm not sure if it would help but it couldn't hurt.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message