[
https://issues.apache.org/jira/browse/DERBY-5766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697391#comment-13697391
]
Kathey Marsden commented on DERBY-5766:
---------------------------------------
Hi Dyre, thank you for working on this issue. I originally became concerned
about this problem working on a case where a user got the read only message
intermittently on a file system that seemed to be clearly writable, so it will
be great to have it logged.
I think it would be ok to log the trace no matter what if made to sound
informational as you say, It might be nice to have a way to suppress (perhaps
if derby.database.defaultConnectionMode=readOnlyAccess?)
> 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
