• 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

Best way to check record locking

 
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I want to make sure that I correctly implement a record locking stategy, satisfying this requirement:


Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available


To test this, I instantiate the class Data:

Then I instantiate a class (DBRead) that is derived from class Thread that has the following run method. During instantiation, I specify the Thread's name and what record number I want to read:

Then I instantiate another class (DBCheck) that is derived from class Thread that has the following run method:

I put both these classes in a loop:

Then start 'em up:

If I create enough threads I see records initially locked, then eventually these records get read.
Is this a valid way to simulate many "nearly-concurrent" requests to the database for the same record, in order to validate the record locking algorithm?
Any comments are welcomed.
- Rolf.
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Rolf,
The best thing you can do is prove to yourself logically that your locking code is correct. Or even better: have some person who is not involved in this assignment review your lock and unlock methods and prove logically that they work. The testing is then just icing on the cake.
The main things I recommend you look for:
  • What happens if two or more threads try to lock an unlocked record simultaneously?
  • What happens if two or more threads try to lock a locked record simultaneously?
  • What happens when two or more threads are woken up by the notifyAll()?
  • Do your instructions require you to handle the case when someone tries to update a record they don't have locked? If so, do you handle it correctly?


  • But to continue with the idea of testing ...
    One of the tests that was regularly recommended in the Fly By Night Services assignment was decrementing the number of seats in a particular flight. If there are 89 seats available on a flight, and we start 10 threads, each removing 3 seats from the flight, then at the end of the run there should be 2 seats remaining, and one thread complaining that it could not book the three seats. Any other result and there was guaranteed to be a problem somewhere
    You could do something similar with your assignment (even if it is one of the new assignments you can just use the customer field as a temporary holder of numbers).
    Regards, Andrew
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic