This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
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

Solve Non Repeattable Read

 
Fernando Franzini
Ranch Hand
Posts: 489
2
Java Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Folks
The situations is:

1. Remote client A read all rooms.
2. Remote client B read all rooms.
3. Remote client B book room 2 with customer id=12345678.
4. Remote client A now have stale view of room 2 that already was booked.
5. Remote client A book room 2 with another customer id.

In SBGD it's a normal situation where one transaction occurs over another updating records.
How do you ranches that passed in SCJD solve this situation

Here go some ideias:
1. Completely ignore and describe in choices.txt ?
2. Implements optimistic lock ?

Regards
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Fernando,

That's why you have lock (and unlock) method for. To prevent 2 clients overwriting each other changes, see ScjdFaq.

Kind regards,
Roel
 
Fernando Franzini
Ranch Hand
Posts: 489
2
Java Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Roel

Lock/unlock is used to manage concurrency e.g the same time. That wasn't I mean !! In this situation dont work.
I mean...when one client stay with stale record in memory after that another updating the record.
 
Bob Wheeler
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Fernando Franzini wrote:
I mean...when one client stay with stale record in memory after that another updating the record.

I check the record before I book the room. If it changed, I throw a Booking Exception (room is not available any more).

cheers
Bob
 
Mark O' Sullivan
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Unless, I'm wrong, but when the second user tries to book the room with the same record number, doesn't 1 just check if it's booked already and doesn't overwrite the previously booking if it's booked? As far as I know, if the room is booked once, that's it, nobody else allowed to book that room. That's all that has to be demonstrated. That's if one is using record numbers, otherwise just check room has been updated with customer id or not.
 
Fernando Franzini
Ranch Hand
Posts: 489
2
Java Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bob and Mark

You are right ranchers !!
What bob did is a kind of optimistic lock...it's was I've thought about.
I'll implement like a bussines rule...inside bussines layer.
Regards.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Fernando Franzini wrote:Lock/unlock is used to manage concurrency e.g the same time.

I don't agree at all.

Concurrency is managed by making your Data class thread-safe, so it is capable of handling concurrent requests without corrupting your data.

The lock/unlock method is used as a locking mechanism: when a client is changing a record, no other client can change the same record. So that's your locking mechanism.

It's quiet important that you are able to see that difference. It is very good explained at the link I provided (but I guess you didn't take the time to read it). Of course just using lock/unlock wouldn't prevent you from overwriting a customer-id, but make it possible to prevent data being overwritten. So you can read the record again (after you own the lock) and then check if it is still available and if it isn't, throw an exception.

Kind regards,
Roel
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Fala grande Fernando!

Champion, here's what I did: before booking a room, I just read it and verify if the customer ID field is still empty. If so, I go ahead and update it; otherwise, a RoomAlreadyBookedException is thrown.

Another thing to mention is, in the scenario you provided, in my case, client 2 would not be notified that record 1 was booked when client 1 books it. This is because I didn't implement an Observer... instead, if client 2 tries to book record 1, then he/she would just notice that this room isn't available anymore after trying to book it. I update the client's data after each time he/she sends/retrieves data from the server.
 
Fernando Franzini
Ranch Hand
Posts: 489
2
Java Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK ranchers
Thanks for the help!

Summarizing, 3 choices was raised to solve this situation:
1. Completely ignore and describe in choices.txt ?
2. Implements optimistic lock, chek record before trigger operation.
3. Notify all clients using Observer pattern.

Any other ideia ?

Regards.
 
Ehsan Rahman
Ranch Hand
Posts: 59
Chrome Netbeans IDE VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As with others, mine checks the record isn't already booked, although it throws a BusinessServiceException("with a comment xyz"), which propagates a message back to the GUI. The user has to refresh for latest data.
 
Fernando Franzini
Ranch Hand
Posts: 489
2
Java Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ehsan

I did the but I didn't refresh....i throw the bussines message warning the user that the room is not avaliable, asking him to refresh they last search. but the application didnt refresh....
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic