• 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

NX Contractors: Requirements Problem. Please Answer!

 
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The DB interface provided by Sun has unlock() throw a RecordNotFoundException.
I hadn't implemented this before and everything was fine.
Then I reread the requirements and it stated that "Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file."
So since Sun wants unlock() to throw this exception, which I think is wrong to begin with, I changed my code to check for a valid record before unlocking.
Now the problem is that this causes a runtime error if you lock before a delete() operation, since an attempt to unlock after that will of course throw the RecordNotFoundException because it was just deleted!
What's the best thing to do in this case? I would really just like to remove record validation from my unlock() method, but I don't want points removed or worse (automatic failure).
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So since Sun wants unlock() to throw this exception, which I think is wrong to begin with
Why do you say that?
Now the problem is that this causes a runtime error if you lock before a delete() operation, since an attempt to unlock after that will of course throw the RecordNotFoundException because it was just deleted!
What's the best thing to do in this case? I would really just like to remove record validation from my unlock() method, but I don't want points removed or worse (automatic failure).

I'd say, don't unlock a record after you delete it. There's nothing there to unlock. Note that this may mean that as part of your unock() code, you need to remove the lock that was associated with that record (assuming you've got this stored in some separate data structure, like a HashMap). But that shouldn't be too difficult. The requiremnts seem clear here - if you try to unlock a record that has been deleted, you should get a RecordNotFoundException. Therefore, don't try to unlock a record after it's been deleted.
[ October 10, 2003: Message edited by: Jim Yingst ]
 
Ramses Tutoli
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But if you don't unlock it, then that record will still be considered "locked" by the application.
What if another thread runs create() and reuses that space? Then that record will be essentially deadlocked, right?
How am I to remove the lock in the first place if I never call unlock() on it?
 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Shouldn't you be locking the actual record object? If you do this, then reusing a reference variable shouldn't be an issue.
 
Ramses Tutoli
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No, I just want to lock record numbers. I'm not even sure what you mean since the records are stored in a flat file.
 
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Ramses,
This is a good question. Instead of calling unlock method as you will normally do say in the booking example as follow:
lock -- read -- update -- unlock sequence.
You do the following:
lock -- delete.
Now you have to manually delete the record from the HashMap which stands for the locking client for this record. This is assuming that you are using a HashMap. If you are using any other data structure say a HashSet or a Vector, then remove it from there. The point is: your delete method must maually remove this record from the logical locking data structure, e.g., HashMap so that other clients don't confuse it for a locked record.
This is what Jim is advising you above.
Hope this helps.
Regards.
Bharat
 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
IMO, unlock method should be called directly from the delete method without checking the validation of the recNo. That's something like what Bharat and Jim talked about.

lock() -> deleted()


I am wondering how Andrew and Mark solved this problem? Same way?
Rick
 
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 Bart,
Welcome to JavaRanch.
We don't have many rules here, but one we do have is our Official Policy On Registered Names. This requires you to have both a first and last name in your displayed name. Could you please add a last name to your displayed name? You can do that here.
Thanks,
Andrew
 
Andrew Monkhouse
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 Rick,

I am wondering how Andrew and Mark solved this problem? Same way?


I did the Fly By Night Services assignment (I think Mark did too, but I also have a feeling that as a gluton for punishment he may have done one of the new assignments when they were in beta), so I did not have this problem - I had other problems
If I were doing it now, I would do as Jim and Bharat have suggested - have the delete() method unlock the record after deletion. That way the client software does not have to call unlock() after the deletion.
I probably would not have the delete() method call the unlock() method though. I would probably have the unlock() method calling several private methods (validateRecord(), validateUser(), removeLock()...), and then the delete() method would call the appropriate private method, skipping several of the steps that the unlock() method does.
Regards, Andrew
 
Rick Lu
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Andrew,
That's something I have done. My unlock() method includes validateUser() and removeLock(). Just like what you had.
Thanks for your reply.
Rick
 
reply
    Bookmark Topic Watch Topic
  • New Topic