1/ you could try to throw UnsupportedOperationException from methods which are not used (like create) and document your decision in choices.txt and maybe you can pass the certification with such an approach, but it's a (huge) risk which might be a really expensive one (if you fail, you'll have to resubmit and take the mandatory course if you resubmit after October 1, 2011).
2/ reusing deleted entries is not a "must" requirement, so you don't have to do that if you don't want to.
3/ Your user does not have to explicit click on a lock/unlock button for updating/booking a record. But before a call to update-method your code needs to make a call to the lock-method. If the record is already locked, the thread
must give up CPU. After the update-method is finished, your code should unlock the record (so it can be locked by another thread). This is a must requirement, so not implementing like described in the interface you got, will result in a failure.
4/ In my application a client is also not allowed to lock more than 1 record, so that's certainly a valid approach. I know which client has a lock on which record, so when a client has already locked 1 record and it tries to lock another one, an IllegalStateException
will be thrown.
5/ I didn't do anythin special for handling client crashes.
6/ for the B&S assignment I think name and location is a valid choice for primary key
7/ For someone who wants to take care of the Data class first, this is a weird question because it has nothing to do with Data class but with the GUI. And there are many threads discussing what should be saved in the configuration file (so you can easily find the answer yourself using the search engine of this forum)