aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: my idea about lock and unlock Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX: my idea about lock and unlock" Watch "NX: my idea about lock and unlock" New topic
Author

NX: my idea about lock and unlock

fei xiao
Greenhorn

Joined: Jan 09, 2004
Posts: 19
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.


SCJP,SCJD
Jacques Bosch
Ranch Hand

Joined: Dec 18, 2003
Posts: 319
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.


Jacques<br />*******<br />MCP, SCJP, SCJD, SCWCD
fei xiao
Greenhorn

Joined: Jan 09, 2004
Posts: 19
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

Joined: Apr 15, 2003
Posts: 619
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 ]

Regards, George
SCJP, SCJD, SCWCD, SCBCD
fei xiao
Greenhorn

Joined: Jan 09, 2004
Posts: 19
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

Joined: Mar 28, 2003
Posts: 11506
    
  95

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


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NX: my idea about lock and unlock