However, i can't see the occasion where i need to throw a RecordNotFoundException
That is right. Can different threads have different file pointers? I think the answer is YES. Back to the locking above, if different threads work on different records and each has it's own file pointer, then there is nothing to worry about since they are writing data to different track/cylinder/segment. Remember that JVM will take care all the stuff about writing your data to the disc(CS303/CS304 "File Structure" right?).
If threads are working on the same record, then there is a risk that the record is over written by the threads. That is why the lock/unlock is required. When a record is locked, there will be only one thread writing data to that record. So this is the reason for the locking(not for the logic). Locking is not to make sure the file pointer working properly. Again file pointer is controlled by the JVM and your operating system, Windows XXX probably. By the other word, how your data/record is written to disc is not controlled by your code. It is by JVM. You don't worry about it.
Now, you see I did complete my school... not dropped out right;-)
My testing shows OK. You may synchronize the context in your update(). It won't hurt. Good luck.
still a bad choice.
I'd subtract points for it were I an assessor, and might cause it to be an automatic failure depending on the exact wording of the requirements document.
Look at your web browser. Is it necessary to guess _any_ address when you click Help->Help Contents (in FF)?
that's the worst possible option.
How would the user know where to find the userguide except from the userguide?
which is downloaded and serves as the stub...
However, you are indicating that you have not used the rmic compiler. This means that at runtime the server JVM must generate the stub files, which must then be dynamically downloaded by the client JVM(s).
Do you think calling first find from client side and then loop read is a good approach, where our DB is sync?
Return types of read and find methods are String[] and int[] respectively. If you see client side, its seems difficult. How client can know the number of matched records to loop read? Putting everything (all records) in single String[] and then sending it to client does not seem a good idea.
Is it a good idea to add more methods in DBMain interface? find method of DBMain returns only record numbers but we need records data to display on JTable at client side.
It can be done at client too after getting record numbers but I am not sure which approach is better. Please comment!!!