Alecsandru Cocarla

Ranch Hand
+ Follow
since Feb 29, 2008
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Alecsandru Cocarla

DocCheck generates HTML reports about how well your code is documented. You should try it
There is also a similar test and ant script - https://coderanch.com/t/189448/Developer-Certification-SCJD/certification/Assignment-submission-file-structure-verification - these are the ones I used (slightly modified) for my assignment verification test and build script.

What is useful in that ant build and you could also add to yours is the javadoccheck target.
Thank you all!!

Leandro Coutinho wrote:Amazing!!!

What was your strategy to change the jpanels? Did you use CardLayout?


No, because from the program's parameters you already know what the layout will be, so there's no need to switch some panels at runtime.
14 years ago
I did not read that article before submitting my assignment, so I just swallowed the exception and continued to wait. However, I don't think I'd have changed my approach. But I had a TimeoutException, which means anyway, after 5 seconds, the thread exits. So swallowing is just a delay, there's no possibility that my thread remains stuck, waiting forever.

This is my "InterruptedException code":

1. See 2.
2. It's not possible, your remote class won't compile.
3. No.
4. Only that Record is Serializable.
Yes. Otherwise, if you have a separate lock manager (not your case) you have to do something like:



The record might be deleted while your thread is waiting for it to become unlocked. If you only check before locking, but not after, then it is possible. There is no problem in locking an already deleted record. create() does not care about locking, so it's still possible to create at that point, read() doe not care either, and update() or delete() can check for themselves if the record is still valid or not.

Roel De Nijs wrote:
your last remark is correct and i would even say it's not needed to throw RNFE from update, delete and unlock (because it should not occur at all, if it occurs your lock-method's implementation or your synchronization/concurrency is wrong)


I think this is the third thread about this problem which was active in the last few days, but I'll say it again - it's not an error as long as you don't recheck after locking that the record is still valid. Update and delete will check again when their turn comes, and that's how they can throw RNFE.
your interface says update and delete can throw RNFE, so how can it be implicitly stated that they shouldn't?
I'd rather have the first post approach, since it's clearer where the exception comes from, which one is possible and which one is not possible.
And no finally block where to call unlock... I don't really like this either.

Aaaaah, I thought your business methods are part of Data... You should have mentioned that from the start

This is what made me think that the code from the first post is inside your Data:

In my implementation all methods are marked synchronized, so when lock is called and record is valid a RNFE being thrown by read/update/unlock could never happen.


From here, I (mis)understood that the code you posted is also synchronized and inside Data.

Now, since your Data is also your lock manager, I understand that when the thread wakes up it will check again if the record is still valid, and won't lock unless it's valid (that's why you don't have to call unlock()).

I'd say IllegalStateException. I wouldn't create a new exception just for wrapping an exception that should never occur. As for assertion, it might also be appropriate, just that in these complex situations, involving threads, I wouldn't trust an assertion. And it's against the principle of "never swallow and exception".

Or... you could disable the re-check inside lock() and let update() check for itself, and you don't have to worry about this issue anymore (Anyway, you'll have to wonder "why did SUN plant this Exception in my interface if it should never be thrown?")

And, again, sorry for the misunderstanding... It's just that I'm not used to giving answers without first seeing if the problem is real or not (or if there are no other problems instead), and only afterwards answering (if there's anything left to answer).
Do you have this statement inside your requirements? I did not have that... Can you copy/paste it from the requirements? Anyway, I said " If your update and delete methods throw RNFE". Do you have RNFE in your update() and delete() methods declaration? It would be strange to have them in your method signatures, but specifically forbidden in the specification...

So, if you don't have RNFE in the method signatures, then yes, you should check before and after locking, and, if needed, unlock and throw RNFE.
As I said, in this case your locking functionality is useless, since there is no possibility that two clients ever do something like:


Since they're synchronized, the operations performed by A and B will always be performed sequentially:


This is perfectly equivalent to:


This is because B cannot even enter the book() method until A finishes its book().
Also, this approach will substantially diminish concurrency. No client will be able to create/read/update/delete anything while another one is inside one of Data's methods.
Why do you insist in checking again after locking? If your update and delete methods throw RNFE, you should just check again inside those methods and forget about the complications with re-checking inside lock().