• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Locking Questions

 
Jeff Hinshaw
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Am working on the URLyBird assignment and need a little clarification on locking individual records.

1) If all of my methods that can change data(update, delete, and create) are synchronized then why is there a need to lock the record? If a client wants to create a record, the create method could be called, determine which record to reuse or append at end of file, then update. Instead of locking and updating.

2) I belive I read if a synchronized method calls another un-synchronized method, that it is basically still synchronized since the calling method was. Can anyone confrim?

Thanks in advance!
 
hatim osman
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi there,
I am not an expert but this the way I understand it. Assignment Instruction states:
Your server must be capable of handling multiple concurrent requests

Therefore, synchronizing the CRUD methods will contradicts the instruction above. Instead I decided to implement an object level synchronization on the file handler, this will never prevent other threads from calling the CRUD methods:




I think you would be fine with this, but let's expect the wrose and hope for the best from others . Any comments?

Hatim
 
Jeff Hinshaw
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I should state that I am having all clients communicate with the same adapter, and not a new adapter for each client.

Also, anyone know the pros/cons of having one or multiple adapters?

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 Jeff,

Consider the situation where two clients both want to book the same record if we are only synchronizing the Data methods:
  • Client A retrieves record 1
  • Client B retrieves record 1
  • Client A checks that it is still available - OK
  • Client B checks that it is still available - OK
  • Client A updates the record
  • Client B updates the record
  • Both client A and B think that they have booked the same record.

    Can you see any way around this if you use logical record locking?

    Also, anyone know the pros/cons of having one or multiple adapters?
    You might be interested in reading "Lockable objects and client IDs".

    Regards, Andrew
     
    Jeff Hinshaw
    Greenhorn
    Posts: 21
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Andrew, thank you for replying. I am fairly new to java and have a hard time articulating my questions non-verbally. I'll try to explain how I understand the assignment(URLyBird 1.1.1)

    1) - I was planning on letting all clients "find" all the rooms they want.
    - The rooms are displayed in a JTable in the clients GUI.
    - clients A and B could be displaying the same room.
    - The find would not "lock" the rooms.
    2) - Client A and Client B decide at the same time to book the room.
    - client A gets lucky and gets to the synchronized "update" method 1st.
    - my understanding is that B is now blocked.
    - A reads the room to verify it is still available and books.
    - B is now in the "update" method. the room is no longer available and b takes no action.

    Like I said, I am new to Java, and especially RMI. But, I thought this seemed logical. I thought RMI would not allow my 2 client threads into the same synchronized method simultaneously.

    In your example, you stated
    - Client A retrieves record 1
    - Client B retrieves record 1

    Did you mean retrieves as in retrieves to display? When a user does a find, should I lock the record while that user is simply looking at it, in which case one user could be locking all records? I don't think this is what you mean, but I need some clarification to make sure I am on the right page.

    Thanks in advance!
     
    Jeff Hinshaw
    Greenhorn
    Posts: 21
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Andrew, thank you for replying. I am fairly new to java and have a hard time articulating my questions non-verbally. I'll try to explain how I understand the assignment(URLyBird 1.1.1)

    1) - I was planning on letting all clients "find" all the rooms they want.
    - The rooms are displayed in a JTable in the clients GUI.
    - clients A and B could be displaying the same room.
    - The find would not "lock" the rooms.
    2) - Client A and Client B decide at the same time to book the room.
    - client A gets lucky and gets to the synchronized "update" method 1st.
    - my understanding is that B is now blocked.
    - A reads the room to verify it is still available and books.
    - B is now in the "update" method. the room is no longer available and b takes no action.

    Like I said, I am new to Java, and especially RMI. But, I thought this seemed logical. I thought RMI would not allow my 2 client threads into the same synchronized method simultaneously.

    In your example, you stated
    - Client A retrieves record 1
    - Client B retrieves record 1

    Did you mean retrieves as in retrieves to display? When a user does a find, should I lock the record while that user is simply looking at it, in which case one user could be locking all records? I don't think this is what you mean, but I need some clarification to make sure I am on the right page.

    Thanks in advance!
     
    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 Jeff,

    2) - Client A and Client B decide at the same time to book the room.
    - client A gets lucky and gets to the synchronized "update" method 1st.
    - my understanding is that B is now blocked.
    - A reads the room to verify it is still available and books.
    - B is now in the "update" method. the room is no longer available and b takes no action.
    Is this Data's update method?

    The methods described in the provided interface do not appear to have any business logic, or indeed any dependancies on the type of data held in the table. So the Data class could (theoretically) be used to work with any type of data and update any field in that database.

    But if you are confirming that a record is still available within Data's update method, then you are tying that method to booking a room (in which case why isn't the method called something like bookRoom?)

    Did you mean retrieves as in retrieves to display?
    I meant retrieve at any point prior to the actual storage of the customer number in the physical table. In your step 2, you mention that "A reads the room to verify it is still available and books." - substitute "reads the room" with "retrieves record". My only difference is that, as explained above, I don't believe that this "reads the room" belongs in Data's update method.

    When a user does a find, should I lock the record while that user is simply looking at it, in which case one user could be locking all records?
    Nope - I think that would be a mistake, since it would drastically reduce concurrency. I don't think there is any value in locking records during the find operation - between the time you return the array of record numbers and when you retrieve the relevant records the data could have changed. Likewise between when you retrieve the relevant records and when you go to book a record the data could have changed. So locking the records will not guarantee you anything, but will stop multiple users performing searches simultaneously.

    Regards, Andrew
     
    Jeff Hinshaw
    Greenhorn
    Posts: 21
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks again Andrew. You are right, and I lost my vision there. My Data class should not have the business logic in it.

    will be updating code/logic for a short while.
     
    hatim osman
    Ranch Hand
    Posts: 105
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Jiff...

    Consider this, when you lock a record for update follow this procedure:

    1. find the record.
    2. if found, check if it's deleted or no.
    3. in case it's a valid record, then lock it for update.
    4. if the record is originally (previuosly being locked by other thread) then the current thread should wait for the lock.
    5. after aquiring the lock, you must check again if it's valid, and check also if it's available for booking. This to ensure that the previouse thread did not delete (Mark as invalid) or booked the record.

    Hope this helps.

    Hatim
     
    Ken Boyd
    Ranch Hand
    Posts: 329
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I am doing like this

    1. in find() method search for all data (depending on serach value) but filter out record which is mark as deleted (flag is available to know that)
    2. Display only valid data (record who is not mark as deleted)
    3. if someone select to book the room.. lock it and update and unlock

    Still I am into server side coding phase (frontend done)
     
    Jeff Hinshaw
    Greenhorn
    Posts: 21
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hakim, might be an issue with your logic:

    1. find the record.
    1. 1. find the record.
    2. if found, check if it's deleted or no.
    3. in case it's a valid record, then lock it for update.
    4. if the record is originally (previuosly being locked by other thread) then the current thread should wait for the lock.
    5. after aquiring the lock, you must check again if it's valid, and check also if it's available for booking. This to ensure that the previouse thread did not delete (Mark as invalid) or booked the record.


    at step 3, if it is valid you suggest to lock it. Someone could have deleted the record after you checked and before you locked you might be updating a deleted record.

    Perhaps it is better to

    1. Lock the record
    2. Read the record
    2. Verify it is not deleted
    3. Update
     
    hatim osman
    Ranch Hand
    Posts: 105
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi jiff

    Thanx, I think you are very much right about this Jiff. I should lock the record even before checking it's validity. Your remarks are valuable.

    thanx
    Hatim
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic