• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Failed assignment, but strongly disagree...

 
Eric Chang
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I managed to fail the assignment with a great 0/80 on the locking where the comment was that it was possible for 2 threads to get the lock on a single record. And it sucks because I managed to almost get a perfect score in everything else (except for 11 point loss on the GUI section).
However, I have thoroughly tested this over and over, and it is simple NOT possible for two clients to get a lock on a single record. I believe this may have been the result of the client calling the lock method rather than all the locking being done on the server-side. I had documented this design decision. I believe that perhaps the assessor may have used an external tool to directly call the lock method directly, bypassing the RMI stub which handles the waiting and notifying.
Who should I write to to dispute this?
[ March 03, 2005: Message edited by: Eric Chang ]
 
Paul Bourdeaux
Ranch Hand
Posts: 783
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry to hear your results. I believe you need to email the who2contact email address and explain your case. They can direct you further. Good Luck.
 
Eric Chang
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, I sent out an email. Unless there's something I'm totally missing, I actually think my locking solution is totally correct...it even handles Clients that crash or close while holding a lock. The only thing I can think of is that they directly called the lock method in my Data.java class, which does nothing to check if another client already holds a lock. Yes, I probably should have put an additional check in there to cover my own ass, but I found no reason to as you cannot get to the lock method in Data.java without first going through the lock method in my RMI implementation of the Server, which handles determining if a lock can be obtained for a record. And I documented this in both my choices.txt AND in the answer in the written exam.
Argh...I hope I don't have to jump though too many hoops and wait too long to get this resolved. The last thing I want to do is spend another $150 just to resubmit my exam with a few more lines of code.
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry to hear that, however, I believe you need to think about whether the case "holding 2 locks for the same record" is really possible. You might test and test and test, however, your test cases might not be the same as SUN's, and thus, what you need to do is to figure out whether this is possible, by trying those cases "mentally", not just run the codes.

Nick
 
Eric Chang
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My problem with what you just said is why should I need to consider any cases that don't involve running a Client and a Server. If you run the Client and a Server, it is not possible for 2 threads to obtain a lock on the same record. If you bypass the Client/Server connection class, then yes, it may be possible for that to happen, but why would one do that and fail me for it when it's specifically documented that the client/client connection handles determining if obtaining a lock is valid.
 
Paul Bourdeaux
Ranch Hand
Posts: 783
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The only thing I can think of is that they directly called the lock method in my Data.java class, which does nothing to check if another client already holds a lock.
I think Sun may look at this as not implementing the required functionality of the interface. This is from the interface provided in my instructions, yours may very well differ:In this version of the interface, it appears to me that the lockRecord method is required to check if another client already holds the lock.

However, as far as I can see, this does not violate any "must" requirement (the only "must" here is that the Data.java class implements the interface, which yours does). So I see no grounds for an automatic failure, and Sun obviously didn't either, as they still graded your assignment. I could see them docking some points in locking, but 0/80 seems unreasonable since you say your code works perfectly when run as a whole application instead of by component.

Good luck with your appeal. I would stress the fact that you documented your decision in your choices.txt, and hope for the best.
 
Eric Chang
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the good luck wishes. I got what seemed like a canned response from my initial email, so I replied with a much more detailed message with the actual comment from my grader as well as reasons on why I think I should not have been failed.
What you said, however, regarding my lock mechanism in my Data class not exactly doing what the comment reads (mine is the exact same as what you posted), leads me to believe that may have been the problem. I suppose at the very least, what I should have done, is throw a RecordNotFound exception with a message stating that a lock cannot be obtained. But still, I think that giving me an outright 0 on locking because of that is excessive. Oh well, let's see how far I can take this before they tell me to stop complaining and resubmit .
If I do resubmit, I don't need to take that exam again do I?
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

If I do resubmit, I don't need to take that exam again do I?

Yes, you dont need to retake the essay exam.

Nick
 
Stephen Loh
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So how's the appeal? Any progress?

Anyway, not too long ago, I posted some replies by a Sun Microsystems representative. This representative claimed that they do not employ automated testing on the submitted codes, so your assumption regarding the accessor running an external tool is out.

My guess is that the accessor examines your code, and found that in the Data class, you didn't perform any checks (as what you have mentioned), and he simply gives you 0 for the locking without ever considering why you didn't do so in the first place. As mentioned, you failed due to insufficient points and not automatic failure, seeing that your assignment is graded.

Anyway, absolute best of luck for your appeal. If I'm not wrong, Sun treats such appeals very seriously and fairly.
 
Eric Chang
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, besides the initial canned response:

Hello,

Thank you for contacting Sun Certification. In order to maintain the integrity
of our exams, we do not release any details regarding our exams. We do not
release additional information that is not already provided in our Assignment Watcher
database:

http://www.certmanager.net/sun_assignment/

However if you have a specific question regarding your assignment, we
will be able to answer you as long as it does not entail giving you the answer.

We apologize for any inconvenience that this may cause.


I haven't gotten anything else. I sent them another email with detailed explanations on why I thought the grading was unfair. Hopefully something will come from that one.
 
Eric Chang
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sigh, unfortunately they have denied my appeal. I've already fixed my code with a new class so that instead of my Data class being a singleton (which is why I had none of my thread safety code in there), there is another layer underneath the Data class which is the singleton.
It seems kind of a shame that maybe 10 lines of "new" code, I will be able to pass the assignment. It's even worse that in the response to my email, they said that my locking implementation worked perfectly fine, but it was solely the fact that I didn't do my thread safety code in my Data class, but rather in the layer above it.
Oh well, hopefully they won't have a different assessor look at it and fail me for something else (I'm still baffled how I got a 71/70...yup, 71, on my meager documentation).
 
Steve Taiwan
Ranch Hand
Posts: 166
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I do hope you pass the SCJD.
If you get the result for the second submission, please let us know.
 
Paul Bourdeaux
Ranch Hand
Posts: 783
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good Luck with the second submission Eric.
 
Eric Chang
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks guys, I'm fairly positive that I'll get it right this time.
 
Liang Anmian
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, good luck with your second submission.

However, there's something that I'm unsure of. What do you mean by the layer above and the layer below the Data class? Does layer above refer to the class that accesses your Data class, and does layer below refer to the class called by your Data class? If yes, actually I don't see any difference with regards to where you implement the checkings. Not sure if I can agree with the accessor's decision to fail you.
 
Eric Chang
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
However, there's something that I'm unsure of. What do you mean by the layer above and the layer below the Data class? Does layer above refer to the class that accesses your Data class, and does layer below refer to the class called by your Data class? If yes, actually I don't see any difference with regards to where you implement the checkings. Not sure if I can agree with the accessor's decision to fail you.


Originally, my Data class was a singleton, and all my thread safety while locking was done in the RMI implementation (each Client connection). So essentially, my lock method in my Data class was useless and did no thread safety checks at all. This is why I believe they failed me (I definitely don't agree with that either...to tell me that my locking worked perfectly but I didn't have my lock method specifically in my Data class do thread checks therefore I get a 0/80 I think is a bit strict). So what I did to fix this is take everything out of my RMI implementation class and stick it into the Data class (except for the throw RemoteExceptions), so my RMI implementation class was essentially a wrapper class calling everything in the Data class. Then, I made a new singleton class which contained everything that USED to be in Data and had every method in the new Data class call those methods.
Yes, it's very unnecessary to do this as I felt my implementation was fine before, and I've done nothing but add a totally unnecessary class, but now my thread safety checks are done in the Data class, and hopefully they won't find another way to fail me.
 
joe lin
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi Eric ,
did you expose the lock method to the client?if you did,and havn't do anything check inside the lock method,i think it is possible(when you are unguarded)to get the same lock by two clients.
 
Eric Chang
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Joe, I made all my checks in the lock method, but it is the lock method in the RMI implementation which does all the thread checking, and then calls the lock method in the Data class. Therefore, I did the proper checking, I just put it in the wrong place, which apparently was enough to get me a 0/80 (and to be fair to the assessor, I still could have passed if I had aced every other part of the assignment, as I don't think he failed me automatically).
Either way, it's water under the bridge, as I am preparing the resubmit in the coming days.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic