Reusing delete entry : issue when reuse the record number
Joined: Apr 16, 2012
I am working on the OCMJD exam. I read this forum since a couple of weeks but this is my first post. I have met an issue in my design and i don't known if i have to add complexity to manage it or if it is a better solution to review my design. I describe my design choices.
First, i choose to implement the reuse of the deleted entries in the data file. I have read in this forum that not implementing this functionnality will not result in an automatic failure but i am surprised when Roel De Nijs says that we don't loose any points. In fact, even if it is not a must requirement, the functionnality is clearly described in my interface :
Then, i defined what is a record number. While there is not any column in the schema for this data, the record number is simply the order of appearance of the record in the data file. The record number has to be used as a key which identifies the record.
Well, with those two considerations i have an issue when running the current scenario :
- Thread A : read the room 0
- Thread B : lock and delete the room 0
- Thread B : create a new room (reusing record number 0)
- Thread A : lock, book (update) and unlock the room 0
Finally, Thread A thinks to have booked the room read before but it is not the case. The desired room has been deleted by Thread B and it the new room created by Thread B that has been actually booked by Thread A.
I am not sure what to do. First, deal with the risk that reusing a key that identifies a data which has been deleted could be considered has a bad practice. Here the interface says to "making the record number ... available for reuse". The problem is the use of the record number as record key but i think i don't have the choice because i don't see any data that could be unique in the data file. I think i could justify the reuse of a key in my design choices.
Then, with the issue itself :
- Don't change the application and explain that there is a known issue that could not appear with the current GUI because it not provides delete and create room functionalities.
- Change the application to manage this scenario. The problem is that it adds complexity in the application. In fact, to know if the room that the CSR wants to book has changed (deleted or updated), my DAO should listen the database changes and keep the record number associated to a timestamp when the event is fired. Then, when the book-method is invoked, a timestamp has to be specified. This timestamp is generated when the CSR has displayed the rooms list. Then the DAO could know if the room identified by the given record number has changed since the client has read the rooms. In this case, when a CSR books a room that has been deleted and replaced by a new room, the DAO could throw an exception to say that the room state has changed and that the rooms list has to be refreshed.
- Change the application and stop reusing deleted entries.
My must-implement interface has exactly the same comments. I didn't mention it in choices.txt and just did nothing about it, because it simply can happen in this application. So it will only be an issue when both create and delete functionalities are available through the GUI and should be taken care of at that moment. Now it's YAGNI.