I have a simple question regarding the difference between the customer ID field of the database and the lockCookie. It appears to me that both determine whether or not a record is available for booking/sale/editing/deleting, so my question is: why couldn't one just use the CSR ID as the cookie to determine whether a record can be updated or deleted? Why the need for an additional identifier?
I fear some deviously simple explanation is eluding me, based on a misunderstanding of their purposes. If anyone could be so kind as to clarify their individual uses, I would be most grateful.
Also, first time here. Hope to learn a lot, and maybe even contribute at some point.
First of all: a warm welcome to the JavaRanch! Hopefully you enjoy your time here.
Now your question. The locking functionality (lock/unlock methods) and making your application handle multiple concurrent requests is one of the hardest parts of this assignment. These topics generate without a doubt the most questions. About the customer id you are correct: it's just a unique identifier to identify a customer. The lockCookie on the other hand doesn't determine whether a record is available for booking, but it's used to make sure that a locked record (using the lock-method) is updated/deleted and unlocked by the same client (thread) as the one who locked the record. So it's a technique to make sure once a record is locked no other thread/client will be able to update/delete/modify the record. Otherwise you can end up with for example double bookings. It's very well explained in ScjdFaq (and this link contains also very valuable information for someone starting this certification).
Clearly there was a bit of a misunderstanding going on. What you have written is of much help. I'm still not totally clear on the distinction, but I think it has something to do threading, which I haven't gotten around to implementing yet (I'm still working on the DB interface methods).