• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

URLyBird Basic QA on Locking

 
Quentin Butler
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All.

Doing URLyBird.

Thought I would start this for people like us that need the basics first.
I have a few questions on the locking part.

1. What should be locked? The whole file or a single record in the file?
2. When should I lock it? When user selects a row or when user clicks bookroom button.
3. Are the steps to follow: Lock, update, unlock ?
4. Once room has been booked, can/must it be unlocked for reuse?

I think that is about it for now. Will send code when I have some idea of what to do.
Thanks.
 
Adam Nace
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Quentin Butler:
Hi All.

Doing URLyBird.

Thought I would start this for people like us that need the basics first.
I have a few questions on the locking part.

1. What should be locked? The whole file or a single record in the file?
2. When should I lock it? When user selects a row or when user clicks bookroom button.
3. Are the steps to follow: Lock, update, unlock ?
4. Once room has been booked, can/must it be unlocked for reuse?

I think that is about it for now. Will send code when I have some idea of what to do.
Thanks.


1. What should be locked? The whole file or a single record in the file?

This is a design decision. It's completely up to you. You are not requird to do one or the other.

However, some solutions are better than others. Think of it this way: Locking is a way of providing "Mutual Exclusion" -> Only one client can access a locked object at a time. period.

Now, when you have a multi-threaded application, the whole point is to acheive high parallelism or concurrency. You want to have as much stuff capable of happening at once as possible.

Now, if you lock the entire database, then only one client can access ANY record at a time.

However, if you lock just one record at a time, then many clients can access records at once, AS LONG AS they are not the accessing the SAME record.

In general, you want to lock the smallest scope possible, for the smallest amount of time possible.

2. When should I lock it? When user selects a row or when user clicks bookroom button.

That is even more of a "you must decide for yourself" issue. Everybody will have different opinions here. If you only lock it when you book, you minimize the time that the record is locked for. This is generally a good thing. However, what if two users click book on the same record at (roughly) the same time. The first one gets through, books the resource, and unlocks the record. Immediately afterwards, the second clients request goes through, obliterates the booking of the first, and overwrites it with a new booking. However, if you force the client to lock it first, THEN draft the appropriate changes and submit them, then a second client will KNOW that somebody else is modifying that file, will have to wait until it SEES the updated results FIRST, before it can decide whether or not to modify that record themselves.

BTW, I hope that when you say "the user selects the row" you don't mean that every time the user places the focus in a row, that it will lock that record. Becuase if you just place the focus in a cell of your table, and use the arrow keys to move up and down, you DEFINITELY don't want to lock and un-lock each record as you go. If you come across one that's already locked? Now you're waiting until the other client moves his cursor and unlocks the records, which could be quite a long time. REALLLY BADDD IDEAAA!

3. Are the steps to follow: Lock, update, unlock ?

Yeah, pretty much. In the process of acquiring the lock, you ensure that nobody is currently modifying the record. Then, while you own the lock, nobody else CAN modify the record. Then, you make your changes, and you don't need to worry about somebody else trying to change it at the same time, leaving it in an undefined state. Then, when you are finished, you unlock the record so that other people can access it if necessary.

4. Once room has been booked, can/must it be unlocked for reuse?

Are you planning on leaving the record locked after it has been booked? Then, not only could the client who locked it be the only one to unlock it, but they would also be the only one who can unbook it. Now you're talking about persistence of locks, as well. What happens when you shut down the server at night for maintenance? YOu have to save the identity of the client who locked the record (which is not necessarily the same as the customer who's name is used to book the record).

Sounds like a bad idea to me. Unlock the record as soon as it's booked, then, if you want to unbook the record, first lock it, unbook it, then unlock it again.

- Adam
 
Quentin Butler
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Adam.

Thanks for the great reply.
It looks like this Locking is quite a problem for most people doing the assignment. I already have the code that will do the locking and unlocking for me but was just not sure about the smaller things. Thanks to you its all a bit clearer now.

Thanks Again.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic