[DERBY-5766] BaseDataFileFactory.boot() should log the exception that causes it to boot the database read only

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 10.9.1.0
• Component/s: Store
• Labels: derby_triage10_11
• Urgency: Normal
• Issue & fix info: High Value Fix, Newcomer
• Assignee: Unassigned
• Reporter: Katherine Marsden
• Created: 16/May/12 16:48
• Updated: 12/Aug/13 12:47

Description

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.

Issue Links

• relates to: DERBY-5686 multiple intermittent errors in nightly tests during DriverMgrAuthenticationTest test. reason: An SQL data change is not permitted for a read-only connection, user or database.