As you will have noted, I have put your source code between [code] and [/code] UBB Tags. This ensures that indenting is preserved, making your code easier to read and comment upon. When you create or edit a post there are buttons just below the text window which will help insert the tags for you so that you don't have to remember them.
I have also removed a considerable amount of your code. Please read the JavaRanch SCJD FAQ, in particular the section titled "What is the policy on posting questions I saw on the exam / details of how to do the assignment?" which explains why posting locking solutions is frowned upon.
Why are you specifying that the lockedRecords collection is final?
This does not really need to be inside your "try" block. The error message used does not match the test - the test is for the record number being "greater than or equal to zero", not larger than one.
You probably don't want to seek to the recNo - you probably need to calculate the position in the file where that record is located .
It appears that if your record is deleted, then you will throw a RecordNotFoundException with no other data than the FinalCommonKey.UNEXPECTED constant.
This constant is also used when trying to handle IOExceptions and InterruptedExceptions - you might want to consider chaining exceptions for these. Alternatively you might want to search in this forum to see other ways of handling the IOException since not all methods in Data class throw RecordNotFoundException.
Since you have a collection of locked records in memory, you don't really need to write the locked status to file. In fact I suspect that there is a logic hole here, if one client tried to lock a record at the same time as another was deleting it:
Client A locks record 5
Client B attempts to lock record 5 - goes into wait state
Client A deletes record 5
Client B locks record 5
In this case client B managed to change the status from deleted to locked
That should give some thoughts to get you started.
It appears to me (unless I'm missing something) that you are writing an indication about the record being locked - to the database itself. I have never seen such an approach taken - usually, all locks are managed in memory.
But this is quite an interesting approach, now that I think of it. Anybody else here is doing the same?
"Large Vehicles Require More Room" - Highway 69 en route to Sudbury, Ontario
Hello Vince, This approach is your own? or yours specs tell you to write a locking flag to the database? My specs literally:
...the new system must reimplement the database code from scratch without altering the data file format. .... Repeat to end of file: 1 byte "deleted" flag. 0 implies valid record, 1 implies deleted record
SCJP, OCMJD, OCMJEA
Joined: Dec 06, 2004
hi, Ignacio i think mine is the same to you.
...the new system must reimplement the database code from scratch without altering the data file format.
i think i don't alter the data file format, only add a flag. but now i don't need use this flag, Andrew told me that when useing Map, i can omit this.
"It appears to me (unless I'm missing something) that you are writing an indication about the record being locked - to the database itself. I have never seen such an approach taken - usually, all locks are managed in memory."
I was thinking about doing it this way. There are some advantages. For example, scalability in allowing multiple machines access to the db file. Better transaction control in that multiple records can now be locked as part of a single transaction. By using a user ID in the field to lock the record, you know who has the lock on the record. In a power failure or the like the db engine on startup has an indication that the db may be in an inconsistent state.
I know these suggestions may be beyond the scope of the assignment. My point is, however, that my initial instinct (before I started reading this forum!) on how to implememnt locking was to lock the record in the file. Also, I don't know whether using values other than -1, 0, and 1 is considered altering the db format.
Nonetheless, I am glad you raised the question because I wanted to discuss the pros and cons. I am still undecided as to whether I'll physically mark the record in the db file.
My leanings are that for the assignment I'll take the conventional route by mapping the recnos to weak references. If I were to program this in real life (in absence of a DBMS), I'd mark the record in the db file.