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

NX : Locking concept question

 
ulvi ugur
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
My assignment reads :
Locking
Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. 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. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.
Now, my question is : Is this locking
a) about synchronization of different threads or
b) about reserving the contractor unless it is released by any user?
c) or both ?
In the database schema, there is no field about if a contractor is reserved or not. So, from the use case point of view :
1) User searches for a criteria in multiple records
2) Finds a subcontractor which matches his criteria
3) ?? (Then what happens, from use case pt. of view ? technically ?)
Probably this is the millionth time sb. is asking a question about locking but question is a question :roll:
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Locking is in this paragraph refers to the record number being locked while a user is trying to book the contractor. This way two users won't be able to book the contractor at the same time.
Basically the contractor is either booked or not booked. So only one user can have a contractor booked. So if two users try to book the same contractor, and the application doesn't handle it cleanly, then it would be possible for both customers to have the same contractor booked, and later you will have one or two really mad customers.
You know a contractor is booked because the customer field is filled in. So in your Use case. step three asks, is this contractor already booked? if so, then you cannot book this contractor, if not book the contractor to the customer.
Now, my disclaimer, This response is based on my version of the COntractor assignment in the Beta version of the exam, so the requirements could be different..
Good Luck
Mark
 
ulvi ugur
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the reply Mark. In that case I don't understand these from my assignment.

// Locks a record so that it can only be updated or deleted by this client.
// If the specified record is already locked, the current thread gives up
// the CPU and consumes no CPU cycles until the record is unlocked.
public void lock(int recNo) throws RecordNotFoundException;
// Releases the lock on a record.
public void unlock(int recNo) throws RecordNotFoundException;

Does this mean, if the record is already locked by sb., I should keep the request of the user in a queue and whenever the record is unlocked somehow (which is not in the scope of the current assignment GUI), lock(reserve) it for the new user ? What if the server fails in the meantime ?
I guess being a non-native English speaker, I struggle more about the language than the assigment itself.
Your help is very much appreciated. Thx.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What that means is that if client A locks record 1, and then client B tries to lock record 1, then client B will wait until client A unlocks record 1.
When client A tries to book record 1 you will basically do this. 1. Lock record, 2. Re-read to make sure you can still book this record, 3. book the record, then 4. unlock the record.
Using threads this is simply using the wait() and the notifyAll() methods of the Object class.
What this means is that the client has to also call the unlock method to unlock the record. So unlocking is in the requirements.
Hope that helps clear things up.
Mark
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12009
216
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ulvi,
Does this mean, if the record is already locked by sb., I should keep the request of the user in a queue and whenever the record is unlocked somehow [...], lock(reserve) it for the new user ?

Not necessarily in a queue. All you have to do is have the thread wait until the record is unlocked then continue from there.
whenever the record is unlocked somehow (which is not in the scope of the current assignment GUI)

I belive it is in scope. You can have two GUI's both attempting to update the same record simultaneously. So each client needs to lock the record (and as mentioned above, only one can do that at a time). Once the client has the record locked, it knows that no one else can update the record. So it can then verify whether the record is still available, and then update it. Then it can unlock the record. Without the lock / unlock sequence, both clients might think that a record is available, and both might update the same record.
What if the server fails in the meantime ?

You don't have to worry about server failure for this assignment (except that you should not write a bad server that crashes ). If the power goes out or some other catestrophic failure, there is nothing we can do about it.
Regards, Andrew
Hmmm: I was preparing my response while Mark was posting his. I agree with what Mark said!
[ September 11, 2003: Message edited by: Andrew Monkhouse ]
 
ulvi ugur
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys,
Andrew said :
Not necessarily in a queue. All you have to do is have the thread wait until the record is unlocked then continue from there.

Would it be an exaggerated case if I imagine that 2 users want to order the same contractor? Do you think I should maintain FIFO in this case ?
Thx guys.
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ulvi,
Would it be an exaggerated case if I imagine that 2 users want to order the same contractor? Do you think I should maintain FIFO in this case ?

You can, but don't have to.
Best,
Vlad
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If two users want to contract the same contractor and both are in a wait state, you cannot guarantee who will get it first when notifyAll is called. Therefore you do not need to implement FIFO for locking. It makes it easier for you not to have to worry about that.
Mark
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic