Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: my idea about lock and unlock

 
fei xiao
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
this is my idea to book a room for a custom. I will lock the record until the custom finishs booking a room or cancel to book.
1. when he click to book button, the system will lock the record if the room is available.
2. he will input his custom id and confirm ( system will modify the record) or cancel the book.
4. unlock the record, then others can access to modify it now.
Is this idea right? when he books the room, no other custom can book this room until he unlock the record.
 
Jacques Bosch
Ranch Hand
Posts: 319
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sounds right.
Lock
book
unlock
should always be what your book button does.
Make sure unlock is still done even if book throws an exception.
 
fei xiao
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jacques Bosch:
Sounds right.
Lock
book
unlock
should always be what your book button does.
Make sure unlock is still done even if book throws an exception.

I process the book with three steps:
1. when you click book, the will have a dialog opened for the custom.
2. the custom enter his id
3. the custom click confirm and the system will modify the record.
Now, I want to know whether I should lock the record at step one and then unlock the record after finished step 3. If I do this, there will have some problems that: if another custom click to book the same record at the same time, the program will be locked too and he can do nothing before the custom locked the record unlock the record. That is to say, if one custom click the book button, then no one can access the record whether the custom may do nothing with the record. It is until the custom close the dialog, then other custom can deal with record.
So I think this one is not a good one. And I just lock the record during step 3. It looks like sound. In this method, there is also have a problem too. If there is a room available, and two custom book it at the same time. For example, A and B. If A look at first but he enter the custom id slower than B, then B can book the room while A lost the book. I don't know whether this method will meet the requirement of the assignment?
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Fei,

I process the book with three steps:
1. when you click book, the will have a dialog opened for the custom.
2. the custom enter his id
3. the custom click confirm and the system will modify the record.
Now, I want to know whether I should lock the record at step one and then unlock the record after finished step 3...
I think this is reasonable. It is OK in my opinion to make another user wait while the user holding the lock books the record for his customer. Could the lock holder take a long time to book the record? Yes, he could, and that means another client may have to wait a long time. If I'm the client waiting for a record to become available, and I'm tired of waiting I can just exit my client GUI and restart (at which point I will no longer be waiting). I think that's acceptable, not elegant, but acceptable. There are more elegant solutions but I think they are beyond the scope of the assignment.
I implemented a dialog that would pop up when the user tried to book a locked record that said: Do you want to wait now for the lock to become available, or do you want to try again later?. So the user could decide to wait (in which case the dialog closed and was replaced with a busy cursor) or the user abandoned the attempt to book the record and could try again later to book the record. I think this is extra functionality not required by the assignment and if I had to do it over again I would not have provided it.
[If] I just lock the record during step 3. It looks like sound...
I don't like this solution at all. The problem with the first solution is minor compared to this one. In this case you're not making people wait (at the end of which wait there's a good outcome), but instead you're being very unfair to client A, who did nothing incorrectly and could rightly assume that from the start of the booking operation he should have had exclusive access to the record in question. Client A is going to be a very unhappy customer and is sure to complain to the customer service representative who is sure to complain to the programmer (you). I can see it rolling downhill already.
Hope this helps,
George
[ January 18, 2004: Message edited by: George Marinkovich ]
 
fei xiao
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As you say, it souds very fair to both custom. But in real system. If all of the business fair are processed by this kind of method. I wonder how many users can this system support?
If this is a booking system for flight. there may be 1000 client to book at the same time and there is only 300 records in the db. If each one lock a record. Then what will happy? Especially for the busy record?
So I would like just to lock and unlock during the step 3. Though it may be unfair to the client A. But it will make the system more effiectly.
Somebody with the experience about this kind situation gives me some detail information about it.
Please offer your advice.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11865
194
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I think it is better to only allow the lock to occur in step 3.
If you have it in step 1, then I think you must incorporate timeouts and dead client recovery.
If you do not have timeouts, then some user who locked a record and then left their PC would own the lock for an unknown length of time. Timeouts are not desirable in the original instructions, but you might make a case for why you must have them in your implementation.
If you do not have dead client recovery, then all those clients who are closing their applications every time they get blocked will still have lock requests remaining.
I do not think there is a good business case for restarting your application every five minutes - I think any manager would get very upset if their employees were saying that they were restarting their applications every few minutes.
Regarding the idea that locking at step 3 is "unfair" to the client, I think it makes little difference to them either way. Locking at step one means that they get notification that record has been booked at the time they click the "book" button. Locking at step 3 means that they get it just after they type the customer ID number and press OK. So we are not talking about a large amount of time. Nor are we talking about loosing a large amount of data. You could even store that data after an unsuccessful booking and offer it as a default on the next booking so that they do not have to re-enter the data.
Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic