I am working on my create method implementation, and I have a couple of questions to see if my reasoning makes sense. Here is a snippet of my code:
First of all, before I create a new record, I run this code to make sure a duplicate one doesn't exist. I read an earlier thread about never throwing DKE, but one of the reasonings were you can't determine a unique record by its "name and location." However, I think testing the uniqueness of a record would be comparing every value.
Next, I compare every value with a .equals() and not .startsWith(). If I used a .startsWith(), there could be a time when an entry could be "Dogs" and the new one, "Dogss". If it ran a .startsWith("Dogs"), then it would be considered, equal, which obviously it is not.
Also, I chose not to test the customerid field. My reasoning is this: A customer could have already booked that specific contractor. However, if I were to create a duplicate record but had the customerid field blank (meaning unbooked) then it would be allowed to be created because the customerid fields would be considered not equal. Then there could be multiple records of a duplicate contractor, some booked, some unbooked. This obviously would defeat the purpose of a DuplicateKeyException. I have noted this in my choices.txt file. I also heard arguments about the possibility of multiple branches of a contractor in the same city, however, I think this is passed the scope of this assignment. When I read the doc, I think the DKE means there should only be one unique contractor, no duplicates.
Next, if the new values are unique, then it will break out of the for loop and will stop comparing values, otherwise it will increment a counter of equal matches. If all fields are equal, it throws a DKE.
Part of my code not shown above trims off any blank spaces in the record values and the data values before comparing.
After this, I am going to search through my cache for the first instance of a contractor object that has a dataValue == null. If none is found, it will create a new contractor object with the next record number. I have heard some debate about checking for a locked and unlocked deleted record before using the implementation above. (I haven't gotten to the locking portion of the assignment yet, though.) My question is this: if a record is deleted, why would it still be holding a lock? I think part of the purpose of delete would also be releasing any locks that it had. This would be part of cleaning up things in my hashmap that stores the lockcookies. If not, what happens if I create a new record using an existing record number of a deleted record? In theory, I will be unable to lock it because the deleted record still holds the lock.
I apologize for the enormous post, but any suggestions or comments are always appreciated. Thanks! [ December 02, 2004: Message edited by: Daniel Simpson ]
My question is this: if a record is deleted, why would it still be holding a lock?
I think you pretty much answered your own question.
The delete method (and the update method) are called from an external class, which will lock the record, call the delete or update method, then unlock the record*. In this scenario, it is possible that you could call create before the external class has released the lock.
Note: * calling lock/delete/unlock might mean that you have to catch an exception from the unlock. Another alternative is to have the delete method unlock the record itself, which bypasses the issue of catching the exception and calling create while the record is still locked.