aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX Contractors: Requirements Problem.  Please Answer! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX Contractors: Requirements Problem.  Please Answer!" Watch "NX Contractors: Requirements Problem.  Please Answer!" New topic
Author

NX Contractors: Requirements Problem. Please Answer!

Ramses Tutoli
Greenhorn

Joined: Sep 05, 2003
Posts: 26
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).
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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 ]

"I'm not back." - Bill Harding, Twister
Ramses Tutoli
Greenhorn

Joined: Sep 05, 2003
Posts: 26
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?
Bart
Greenhorn

Joined: Oct 10, 2003
Posts: 3
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

Joined: Sep 05, 2003
Posts: 26
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.
Bharat Ruparel
Ranch Hand

Joined: Jul 30, 2003
Posts: 493
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


SCJP,SCJD,SCWCD,SCBCD,SCDJWS,SCEA
Rick Lu
Ranch Hand

Joined: Mar 25, 2003
Posts: 47
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


SCJD 1.4
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11460
    
  94

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


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11460
    
  94

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

Joined: Mar 25, 2003
Posts: 47
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NX Contractors: Requirements Problem. Please Answer!