• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

(B&S) Business Method

 
Saheed Adepoju
Ranch Hand
Posts: 267
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all
I would like an insight into this scenario, I have an Adapter class with a
business function Book() that calls lock(),read(),update(),unlock() in that sequence:

Imagine:
Two thread wanting to book a particular record 1:

Client 1 calls book()
Client 1 calls lock()
Client 2 Calls book()
Client 2 calls lock() -- waits()
Client 1 calls read()-- sees that the record is available for booking
Client 1 calls update()
Client 1 calls unlock()--notifies all waiting thread
Client 2 acquires lock()
Client 2 calls read()--How do i disallow client from booking?
Client 2 calls update()-- overwrites Client 1 booking!!!
Client 2 calls unlock()--notifies all the waiting thread

Well that is my scenario, and i had this for a solution. Have a data structure
within the Adapter class that checks for booked records?Is this ok?Could i add a function for
unbooking a clients booking? It seems from the scenario i gave, it would cause the clients to overwrite each other's
bookings right? IMO I believe that if the locking works well, i shouldnt bother myself about overwriting each clients bookings? Please correct me if i am wrong! Thanks!
 
Sam Codean
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You must be having some method that will determine if the Record is valid for updation if i am not wrong. In that case the checking method will also have to be called after obtaining the Lock.

So it becomes
Client 1 calls book()
Client 1 calls lock()
Client 1 calls isAvailable()
Client 2 Calls book()
Client 2 calls lock() -- waits()
Client 1 calls read()-- sees that the record is available for booking
Client 1 calls update()
Client 1 calls makeUnavailable() -- in case this update is to be saved
Client 1 calls unlock()--notifies all waiting thread
Client 2 acquires lock()
Client 2 calls isAvailable()-- Here it will decide that it cannot be updated (In case it is dirty)
Client 2 calls read()--How do i disallow client from booking?
Client 2 calls update()-- overwrites Client 1 booking!!!
Client 1 calls makeUnavailable() -- Here it will again mark unavailable if required
Client 2 calls unlock()--notifies all the waiting thread

You can add more logic to determine when the record is to be made available
Hope That Helps!!
 
Ed Tse
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't have the B&S assignment, but I'll try anyway.

Can't your adapter's update interface requires an record before update and after update. So when client 2 acquired the lock, and perform a read, the adapter class will try to match it against the record before change that client 2 pass in, if it's the same, he can perform the update.
 
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 Saheed,

Since your book() method is a business method that you have created in a class that you defined, then I think your book method will be calling the following:See that bit that I have labeled as missing logic? After doing the read() your business logic can determine if the record is still available or not. If it is not still available, you can throw an exception to show that the booking cannot continue.

Regards, Andrew
 
Saheed Adepoju
Ranch Hand
Posts: 267
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all
Thanks for your responses, i also thought in that direction. But my thoughts brought me to think i would have the client "sync" on a data structure say a vector before that they actually call lock on the data record. They check the Vector to see if the requested recNo is already there, if it is then it throws an AlreadyBookedException(extends RuntimeException),if not then it goes on ahead to lock on the record and make the booking. It would make it easier to unbook the record by simply removing the recNo from the vector. I dont know if it makes sense but i like the idea. Thanks as you make your inputs.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic