Hi Morph -
To resolve this question, consider what happens when any two clients attempt to use the same record at one time.
Let's say you are in the middle of modifying record 5, and I decide to modify it as well a few milliseconds later. If there's no code to make the act of modifying that record an atomic operation, there might be several permutations for the result. Since this must be a multi-threaded system, and the order in which threads are selected to run is not determined from our point of view, it may not be clear what result we get. For example, let's say we are modifying the contact information. One scenario in unsynchronized code might be that your changes (first and last name) get saved along with mine (address, city, state). If we think we've both updated the record successfully, the result is not too useful.
Deleting records without locking the table is a problem for operations that might scan all records in the table. Let's say I decide to loop through all 50 records and perform some table-wide operation. I get a count of 50 records and start my loop. In the meantime, you come in and delete a record. Now after I get past record 49, I'm going to have a problem, because my loop thinks there are going to be 50 records.
In short, we synchronize to protect against not the probability of misfires, but the possibility of them. Without that protection, we end up with the possibility that some cases for output are not determined by our code. That's bad on Exam code, but only because that problem is far, far worse when it finds its way into production code.
------------------
Michael Ernest, co-author of:
The Complete Java 2 Certification Study Guide
[This message has been edited by Michael Ernest (edited August 25, 2001).]