Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

why do I even need to lock?

 
Yuan Ye
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As I read more, I am more confused. So I even ask this silly question!
As my specs said "You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server."
Since I can assume at any moment, only one thread is accessing the db file, then why would I worried about deadlock? If two thread want to update a same record, the assumption has guarenteered that they must be in some order ( since one thread is allowed to touch the db file ). Why should we care about record locking?
I know I must be wrong, just need someone to correct me. Thanks
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can assume that only one program (yours) is accessing the DB file. But your program may well have more than one thread running. If you use RMI, the RMI implementation will probably start multiple threads whether you want them or not; there is no way to guarantee RMI does not do this, as it's part of the RMI spec, so you have to deign for multiple threads if you use RMI. If you use sockets, well, it is possible for you to write the code in such a way that only one thread ever responds to any requests received by any socket. However this is probably pretty inefficient; most good socket imlementations will probably use multiple threads at some point to process data. Plus, I suspect that one of Sun's design goals for this assignment was to see how well we as developers are able to handle thread-safe programming. If you avoid the issue by avoiding any thread creation, they may well be annoyed and seek to penalize you. That's just a guess though.
 
Yuan Ye
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,Jim, Thanks for your reply.
I have a further question which have been asked before in this forum but I can't find a good answer. It is about how to access the db file.
We know it is allowed for mutliple RandomAccessFile to access a same file of different records, but I think that's not so thread-safe, is that true? Most people said they are using a single instance to do all the file IO operations, by synchronize all the method, it will be quite thread-safe. However I am thinking that this may cause the record lock redundent.
The reason is that since at a time only one thread(instance) is allowed to access the file, then why do we bother to lock a record? So I think this is also not good. What should I do? Thanks
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Peter,
Record locking is quite separate from the issue of whether the calls to the RandomAccessFile are thread safe or not.
Each contractor can only work with one "owner". That is, if two clients simultaneously decide that they want to book "Moore Power Tool Ya", what happens?
  • Client A asks for a list of available contractors
  • Client B asks for a list of available contractors
  • Client A sees that "Moore Power Tool Ya" is available and enters the owner information
  • Client B sees that "Moore Power Tool Ya" is available and enters the owner information
  • Client A clicks the Book button
  • Client B clicks the Book button


  • What happens next? Both clients thought that the record was available, so both could click the book button simultaneously.
    You are going to have to ensure that only one booking succeeds. To do this, you will almost certainly need to use the lock methods.
    Regards, Andrew
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic