• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: (HOTEL) Dirty reads

 
james render
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does my locking solution need to prevent dirty reads?
I searched the forum and found this discussion dirty-reads
in which it argues that you don't need to take
dirty reads into consideration because of wording
of the requirements.
BUT with the new projects there is no mention of
'read' locks and 'write' locks AND the scoring (on the URYLBIRD anyway) gives locking 80 points - double most other sections.
Does this mean I need to solve the problem of dirty reads - and if so the simplistic (compliment!) solution in Max's book would need amendment??
anyone following me here??

thanks for your time guys..
J.
 
james render
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Having decided that better safe than sorry, I've decided to (try to ) prevent dirty-reads.
Also re-read Max's example where each method on DVDDatabase is synchronized on top of the individual DVD locking.
I didn't want to alter the method signature (synchronized isn't part of method signature though ??) so I put around my reads/update and delete.
Could this lead to deadlock contention?
J.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Really simply put, only one client can have a lock on a record, and therefore another client cannot be editing and modifying the record at the same time that another client is. So you will not get any dirty reads.
The policy of lock-read-modify-unlock will prevent any possibility of dirty reads. Say clinet A sees Hotel A with a room available. The client selects to book the room. It then locks the record and rereads it to make sure that it is still available. If it is not then the method stops and the client is notified that room has been booked. If it is available, then the client books it and that is that.
When Client A's first read the record to be put in the JTable it was available, and therefore good data. The read after lock is to verify the data. This is the solution to "dirty reads" and should be all that you need to do.
Good Luck
Mark
 
james render
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Really simply put, only one client can have a lock on a record, and therefore another client cannot be editing and modifying the record at the same time that another client is. So you will not get any dirty reads.
The policy of lock-read-modify-unlock will prevent any possibility of dirty reads. Say clinet A sees Hotel A with a room available. The client selects to book the room. It then locks the record and rereads it to make sure that it is still available. If it is not then the method stops and the client is notified that room has been booked. If it is available, then the client books it and that is that.
When Client A's first read the record to be put in the JTable it was available, and therefore good data. The read after lock is to verify the data. This is the solution to "dirty reads" and should be all that you need to do.

You've dealt with the 'update' scenario here. What about the create, recover and delete scenarios (as I've implemented them as well).
The issue that I was concerned about is whether to implement any locking when undertaking record reading.
<delete>
thread a locks a record, thread a reads the record to be deleted, thread b comes in to read, gets the record, doesn't think its deleted, thread a deletes the record
not sure if making any sense, its late and I've got my girlfriend storming round the house as I promised not to work late
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
create, delete, and recover are not requirements in the instructions.html. You are going beyond the requirements and causing youself extra work for no gain. You will not gain any points for this, and in fact stand more of a chance of losing points.
I hate to see you lose any points as it appears that you understand databases really well and the problems that could result in not taking care of them.
One of the main points in the assignment is how well you follow directions and don't go overboard. Please don't worry about dirty reads.
Mark
 
james render
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks Mark,
the debate on whether to include create/recover/delete functionality has raged on elsewhere on the forum. I think that Max concluded that it should be included but not used by the clients
having decided that it was better safe than sorry I have included it.
your point about lock/read/modify/unlock was very appropriate and something that I hadn't yet thought of.
i shall take a 'dirty read' chill pill
 
Bob Reeves
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All:
I don't think the cookie prevents a "dirty read". The update process is not atomic, either for all fields or for any one field. Thus, the cookie holder could be updating record N, but timeslice out in the middle of writing "BigBen" in the Hotel field. If a client were to read record N at that exact moment, it might read "Bigville". True, one could argue that it really doesn't matter since its just the search screen. Still ...
Tx
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As brought to my attention by Jim, I should also state that many of my arguments are based on the SCJD requirements and sticking to them rather than going beyond the specs.
Thanks Jim
Mark
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Mark: IMO, sticking to requirements should probably be the primary guiding light on this assignment.
M
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic