Are we to rely solely on our own defined record locking mechanism and provide no synchronization in the class that accesses the database file?
My code is synchronized and works fine even if I don't call my lock or unlock methods. The worst that happens is a RecordNotFoundException is thrown if the record doesn't exist or is marked as deleted. So it seems my lock and unlock methods don't provide any added value.
I think you are asking the same question in different ways in your 2 threads, so I am going to post this reply in both. (Thanks for taking the time to rephrase your question though).
You might want to look at the JavaRanch SCJD FAQ. In particular the section on "Can't we synchronize the update() method and ignore the lock() methods?" which is also the same as the section "Why do we have lock() methods in the Data class?"
Thanks Andrew. Your book has been an invaluable resource to me in this little adventure.
The FAQ makes perfect sense, and I realized why it was that there seemed to be no difference in my testing results if I called lock/unlock before modifying a record or not: I was using my Data class as a facade and passing in an the instance of my Data class to my LockManager as the "cookie" to identify the client, then storing the recNo and Data instance in a map. A couple of days ago I decided to make my Data class a singleton... so every client had the same instance. The portion of my lock method checks to see if the current client already owns the lock, and if so, returns.
I decided to change my cookie from an instance of the Data class to Thread.currentThread(). My tests run MUCH cleaner now, and I only get legitimate invalid record warnings when a thread is waiting for the lock on a record and the previous owner deletes the record. And based on the fact that I wasn't really doing any record locking before, I'm guessing my synchronization blocks are correct