• 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • salvin francis
  • fred rosenberger

Thoughts on synchronizing, implementing delete and on locking

Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've worked on my Fly By Night assignment for a week and am almost done, but I have a few lose ends... I would like to know if the methods in the Data class should be synchronized or not after the lock and unlock methods have been implemented.
1. As I see it, the only purpose of locking on record level is the ability for the server to handle multiple modification requests, thus it can modify two unlocked records simoultanasly. But if the modify method is synchronized, this ability is lost, since only one call can execute the method at a time.
I'm opting to remove the synchronized modifier from the modify method because it's of no use, am I right?
2. I also want to know if you are required to implement delete functionallity even though delete is never used in the assignment. Delete would neeed to in fact lock all the records since the number of records will change, thus the locks Vector or Hashmap or whatever will be invalid after a delete, and must be recreated.
3. A final thought is the original Javadoc comment that was included for the unlock method in the original Data class:
* Unlock the requested record. Ignored if the caller does not
* have a current lock on the requested record.
public void unlock(int record) {
But how can you ever know if specifically the caller has a lock or not, when you just pass the record number to the method? You don't have a reference to the caller. hmmm...
High Plains Drifter
Posts: 7289
Netbeans IDE VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Brian -
Congratulations on your progress with the exam! It can be a long road, but I hope you're learning something from it.
I'd like to respond to some of your thoughts:
1. The true purpose of locking on the record level is to make you demonstrate you know how to do it -- it's a test, after all. Seriously though, you can achieve a more efficient utilization of the data store, by reducing the scope of synchronization to the most granular operation that makes sense.
It seems like you've imagined a queue at modify(), after which nothing else can happen. In fact, anything else can happen concurrently -- except another modify() request. So if other connections are being processed outside of this call, they needn't wait for a modify() to complete to do their work. *Only* other modify calls have to wait. Now, in a world where nothing but modify() ever gets called, there's no benefit. Otherwise, you leave the door open for everything else, which can result in a more efficient execution of the program.
2. To really test your understanding of collections, implement delete(). This is a classic example of why you'd want to lock the whole database object, and not just a record, since proper iteration is at stake.
3. A tease hint: Would it make sense that the object that's assigned its lock would know who has it?
Good luck! It sounds to me like you're facing all the right challenges.
Michael Ernest, co-author of:

    The Complete Java 2 Certification Study Guide

    [This message has been edited by Michael Ernest (edited December 19, 2000).]
Brian Thorne
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Michael for your response...
I've come to realize that the lock/unlock procedure has more to it than I thought. Its main purpose (as I see it now) is to perform a transaction. That is:
1. Lock the record to make sure no one else can modify it.
2. Read the record to make sure you have the latest data.
3. Check if the entered number of seats can bee booked
(the new value for seats must not be less than zero)
4. If the value isn't valid, unlock the record and inform the user. (Rollback)
5. Write the record. (commit)
6. Unlock it.
Unlocking would be best to do in a finally block to ensure that even if an exception is thrown, the record will still be unlocked.
Thus, it has nothing to do with synchronizing data access. I realized this afrer reading the spec once more, I hope I'm on the right track.
As for delete. I will implement it, but is it required?
Merry Christmas everyone!

[This message has been edited by Brian Thorne (edited December 20, 2000).]
Yes, of course, and I accept that blame. In fact, i covet that blame. As does this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
    Bookmark Topic Watch Topic
  • New Topic