db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dyre Tjeldvoll (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5766) BaseDataFileFactory.boot() should log the exception that causes it to boot the database read only
Date Mon, 01 Jul 2013 21:45:21 GMT

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

Dyre Tjeldvoll commented on DERBY-5766:

I'm considering assigning myself to this issue, but I don't really understand the objections
to the obvious solution:

- Why can't we log the exception trace if it is a permission error?
- Or if the database media is read-only?

The fist may be doable if all permission exceptions share a common base class. The latter
I think is difficult since all you get is an IOException, and AFACT there is no subclass that
would cover the RO media situation. So then your only option is to start parsing the IOExeception's
message to see if this could possibly be RO media. I don't think that is going to be portable
across OSes or Locales. And even if the media is RO you cannot know if the user intended to
boot the DB RO - she could just have entered the path to RO media by mistake - so a warning
about booting RO could still be useful. 

Personally I don't like error messages that try to make the software seem smarter that it
is. If the algorithm simply tries to grab the lock, and then boots the db RO if that fails
-  then that is what user should be told. Preferably expressed in such a way that those who
intended to boot RO are not scared into thinking something is wrong. E.g. "Failed to obtain
db lock. Will boot db 'wombat' in RO mode. If this not expected/desired, the following stacktrace
may help identify why the lock could not be obtained: ", or something like that...
> BaseDataFileFactory.boot() should log the exception that causes it to boot the database
read only 
> --------------------------------------------------------------------------------------------------
>                 Key: DERBY-5766
>                 URL: https://issues.apache.org/jira/browse/DERBY-5766
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:
>            Reporter: Kathey Marsden
>              Labels: derby_triage10_10
> In BaseDataFileFactory.boot() there is code that tries to write to the lock file. If
it cannot, and gets an IOException  it assumes the database is read only.  I think that we
should log that the database is booting read only and why and if it is not specifically a
permission error log the exception stack trace.
>            fileLockOnDB = fileLock.getRandomAccessFile( "rw");
>             fileLock.limitAccessToOwner();
>             // write it out for future reference
>             fileLockOnDB.writeUTF(myUUID.toString()); 
>             fileLockOnDB.sync();
>             fileLockOnDB.seek(0);
>             // check the UUID
>             UUID checkUUID = uuidFactory.recreateUUID(fileLockOnDB.readUTF());
>             if (!checkUUID.equals(myUUID))
>             {
>                 throw StandardException.newException(
>                     SQLState.DATA_MULTIPLE_JBMS_ON_DB, databaseDirectory);
>             }
>         }
>         catch (IOException ioe)
>         {
>             // probably a read only db, don't do anything more
>             readOnly = true;
>             try
>             {
>                 if (fileLockOnDB != null)
>                     fileLockOnDB.close();
>             }
>             catch (IOException ioe2)
>             { /* did the best I could */ }
>             fileLockOnDB = null;
>             return;
>         }
> I think this code can be exercised by creating a database and exiting without shutdown.
Then change permission on the db.lck  and dbex.lck files. It occurs often in the field when
multiple users with incompatible permissions/umasks access the derby database.

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

View raw message