NX Contractors: Requirements Problem. Please Answer!

[Ramses Tutoli]

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]

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]

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]

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]

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]

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

[Rick Lu]

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

[Andrew Monkhouse]

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]

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]

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