You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Dyre Tjeldvoll (JIRA)" <ji...@apache.org> on 2013/07/01 23:45:21 UTC
[jira] [Commented] (DERBY-5766) BaseDataFileFactory.boot() should
log the exception that causes it to boot the database read only
[ 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: 10.9.1.0
> 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