• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Locking the record

 
Alex Balaban
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I can quote the requirement: "If the specified record is already locked by different client, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked."

It looks like I have two options:

1. On edit lock the record for entire time unless submit/cancel button is pressed. This will, of course, cause any other client to block until the first client is done and unblocks the record.
2. Lock on submit. This would be short enough, but now two clients can edit at the same time, then submit - and one of them would wonder where that data is coming from...

I wonder if people that already done the exam think that option #2 is acceptable.

I think we cannot do any better without elaborately ignoring and bypassing the given DB interface. I can decouple that blocking thread from rest of application using Observer pattern or something, but, then it (DB interface) looks so useless that it cannot be the purpose of the assignment.

Thanks

Alex
 
K. Tsang
Bartender
Posts: 3583
16
Android Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
IMO option 2 is the way to go. You should aim for minimum record locking (eg only during writes). Also it's not possible to lock a record forever because you won't know which record to lock in the first place.

Given if you lock a record when the "book" window pops up, that user goes for lunch... Other users can't book that particular record ... Therefore lock on submit (do the lock->update->unlock) and return to the client making the client interactive. If your locking mechanism doesn't work, your client will hang meaning you've got deadlock somewhere.

Locking is the most important aspect of SCJD if you don't have it working properly, you can't pass!!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic