[
https://issues.apache.org/jira/browse/DERBY-5766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697230#comment-13697230
]
Dyre Tjeldvoll edited comment on DERBY-5766 at 7/1/13 9:50 PM:
---------------------------------------------------------------
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 AFAICT
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 is not expected/desired, the following
stacktrace may help identify why the lock could not be obtained: ", or
something like that...
was (Author: dyret):
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
