This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I have being thinking about the RandomAccessFile db implementation in my version of the project and in my opinion there is a major time incompatibility problem in the requirements.
Basically, the problem is that there is only one file pointer in the RAF (even with NIO channels opening within each method the specs state clearly that the channel points to the file pointer of the underlying object). This means that any simultaneous read or write operations will result in unspecified behaviour unless we totally synchronize all access through e.g. some static object. Now we can have multiple clients and we can cache up information to permit read access without this problem.. but we have lost the point of having record locking. At the end of the day, every access to the database will have to be one by one or be unthreadsafe.
Are we supposed to ignore this? (I am guessing that there is at least a 50% chance that this is true). Or did others make access one by one, and go through the motions of creating record locking?
I think you'll still be fine as long as you only append at the end of the file and the record "adding" is synchronized. As far as I can understand, this would only become a big issue if the "start of record" position becomes invalid in the middle of a "write" operation.
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1