• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

The role of logical record locking?

 
Ranch Hand
Posts: 57
Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi folks,


Ive been trying to understand just how logical record locking is supposed to prevent two uers/clients from booking the same record, hence overwriting each other. Below is some background info about my assignment after which I'll lay out the scenario which Im trying to figure out.


Assignment Info
-----------------
URLyBird 1.1.1

Signature and comments for lock method:
// Locks a record so that it can only be updated or deleted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated, or deleted. If the specified record is already locked by a different
// client, the current thread gives up the CPU and consumes no CPU cycles until
// the record is unlocked.
public long lock(int recNo) throws RecordNotFoundException;


Signature for unlock method:
// Releases the lock on a record. Cookie must be the cookie
// returned when the record was locked; otherwise throws SecurityException.
public void unlock(int recNo, long cookie)
throws RecordNotFoundException, SecurityException;




Problem scenario (without logical record locking)
Consider two clients A and B.

1.) Client A retrieves all records and this is diplayed on the screen in the JTable
2.) Client B retrieves all records and this is diplayed on the screen in the JTable
3.)Client A selects record 1 and client B also selects record 1 (this record's owner field is empty so both clients can tell from there that the record is available)
4.) Client A attempts to book record 1 and in so doing calls the update method (directly or indirectly, yet to decide) in Data class. I intend to synchronize access to the update method so that when client A's thread enters the update method no other thread can enter until client A releases the Data object's lock.

5.) Similarly, Client B attempts to book record 1 but cannot proceed because client A has not finished executing the synchronized update method in the Data class. So Client B will block until Client A finishes the method and releases the lock (note that in the update method, i'll check whether the record is still available before updating the record)

6.) After Client A finishes the update method and releases the Data object's lock, Client B attempts to continue and enters the synchronized update method to perform its booking. However, when it checks whether the record is still available, it finds that it is no longer available and so it can't book it. So the thread returns and the client is notified that the record is no longer available.


My question:
The whole point of logical record locking is to prevent two or more clients from booking the same record and hence overwriting eachother's booking. However, from the scenario I have above, I dont see how two clients can overwrite eachother's booking because of the check i'll introduce in my update method to see whether the record is still available. Is there something Im missing here?



*I have not done any coding


Cheers!
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your update method is not supposed to check if the record is still available! Your update method should just update all fields and that's it.

The contract of the update method is updates each field of the record and not "update each field if the record is still available". Your Data class should not contain any business logic, so it can be easily re-used for the management of a similar customer database file (code reusability)
 
Ranch Hand
Posts: 221
Scala Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Olu,

Please check the FAQ here.
There is also a pretty good writeup about this in Chapter 5 of the Monkhouse book.

HTH,

Carlos.

 
Olu Shiyan
Ranch Hand
Posts: 57
Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Spot on guys, that makes a whole lotta sense to me now. However, the Monkhouse book and the link in your last post talks about locking the record before checking for availability. This throws up another question in my head:

After locking a record successfully, the client program still has to check whether the record is available, despite the fact that the record's owner field is empty in the JTable (after a find operation meaning its available)?


Thanks
 
Carlos Morillo
Ranch Hand
Posts: 221
Scala Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Olu Shiyan wrote:After locking a record successfully, the client program still has to check whether the record is available, despite the fact that the record's owner field is empty in the JTable (after a find operation meaning its available)?



From a business logic layer perspective a data record can be locked. Once it is locked the owner field could have the "" empty String
or have "12345678" and up to you to decide what action to do according to the purpose of that business logic operation (maybe
you can throw an RoomAlreadyBooked exception if you are booking).

It is up to you to make some assumptions of the semantics of each case to what that case means.

You also need to do this check because your Database server is supporting multiple clients and it could have been booked by another
client between the time you saw it as "" in the GUI and the time you hit the Book button.

Now from a Presentation layer perspective (Swing GUI, web page, etc.) you can make some assumptions for the data records
in your JTable to disable the book operation when the owner has a value different than the "" empty String.


HTH,


Carlos.
 
reply
    Bookmark Topic Watch Topic
  • New Topic