pass scjd, graded in 4 days.

Thanks for your help, ranchers, I just passed the scjd, not very exited score(I was expecting more. very disappointed about my lock/unlock), but amazing speed: only 4 days after I uploaded the submission. here is details

Test: Sun Certified Developer for the Java 2 Platform (310-027)
Date Taken: 2006-07-01 13:38:54.090

Grade: P
Score: 358
Comment: This report shows the total 1.4 SCJD points that could have been awarded in each section, and the actual number of points you were awarded. This is provided to give you per-section feedback on your strengths. The maximum possible score is 400; the minimum to pass is 320. General Considerations (maximum = 100): 99 Documentation (maximum = 70): 70 O-O Design (maximum = 30): 30 GUI (maximum = 40): 35 Locking (maximum = 80): 44 Data store (maximum = 40): 40 Network server (maximum = 40): 40

Congrats !!!

Why so less on locking ?

Regards M.

I want to know why I lost point on locking too, I did stress test for 150 concurrent users, simulate test for different cases. gee, what did I miss ? what did I miss!

Thank you, Mihai Radulescu.

Congratulations!!!

Congratulations Ivory

Personally I thought that was a good score. Only 1 point lost in General Considerations. Only 5 points lost in GUI, and the only other area is the infamous 44/80 in locking.

[QB]Originally posted by Ivory Lee:
gee, what did I miss ? what did I miss!

How well does your code handle the following scenario:

Client A requests lock on record 5 - granted

Client B requests lock on record 5 - wait state

Client A deletes record 5

What happens from that point onwards?

Will client B ever come out of wait state?

Will client B be granted the lock on record 5 or will an exception be thrown?

Regards, Andrew

Thanks, Andrew, thanks for your accompliments

.

>>How well does your code handle the following scenario:
>>Client A requests lock on record 5 - granted
>>Client B requests lock on record 5 - wait state
>>Client A deletes record 5
>>What happens from that point onwards?
>>Will client B ever come out of wait state?
>>Will client B be granted the lock on record 5 or will an exception be thrown?

Actually, I testes this case by running two threads, client A is holding the record lock and sleep(100), and Client B request again, then the A delete the record. B will wake up and throw the RecordNotFoundException.

Is my thread test case right?

Regards.

Ivory.

Sounds right to me. (That is the usual test case that is forgotten).

Regards, Andrew

Thanks, Andrew, thanks for your accompliments

.

>>How well does your code handle the following scenario:
>>Client A requests lock on record 5 - granted
>>Client B requests lock on record 5 - wait state
>>Client A deletes record 5
>>What happens from that point onwards?
>>Will client B ever come out of wait state?
>>Will client B be granted the lock on record 5 or will an exception be thrown?

Actually, I testes this case by running two threads, client A is holding the record lock and sleep(100), and Client B request again, then the A delete the record. B will wake up and throw the RecordNotFoundException.

Is my thread test case right?

Regards.

Ivory.

Does this mean you guys have treated delete differently?
In update:
lock, update, unlock.
but in delete:
lock, delete.

So, do I have to unlock the record in the delete of my Data.java?

Originally posted by John McBird:
Does this mean you guys have treated delete differently?
In update:
lock, update, unlock.
but in delete:
lock, delete.

So, do I have to unlock the record in the delete of my Data.java?

If one and only one client is connected then "lock-delete" sequence is sufficient, because no one else wants to work with the record. But think about scenario, where clientA wants to delete record and clientB wants to update the same record in the same time. If clientA don't unlock the record, then clientB will be blocked forever.

That is not what I said!
From what Andrew said, Client A locked and deleted.
Andy asked what happened after that. If client A does not unlcok, client
B is locked forever.

Now, what is the reason for Data.java to keep a deleted record locked?
Cannot we just merge delete and unlock together?

How will Sun test my Data.java? Will they change there test if I tell them
if you delete then you have to follow it with unlock?

That is my question!

Hi John,

u are right. I haven't understood your question correctly.

In standalone mode there is no need to use locking mechanism at all. In this mode calling unlock() is redundant (or even incorrect).

Bob, what are you talking about??
We need to use the interface to do stuff. We have to lock even in standalone
as the delete/update require a cookie!!!

Now, for delete I think we need to lock then delete in both standalone and
entwork. In addition, delete should remove the lock after it deletes the
record.

Originally posted by Eva Van Shtock:
Bob, what are you talking about??
We need to use the interface to do stuff. We have to lock even in standalone
as the delete/update require a cookie!!!

it depends - operations in my interface don't require any cookie.

taken from my SJCD document:
"(..) therefore your locking system only needs to be concerned with multiple concurrent clients of your server"

in standalone mode there is only one client, so calling lock(recNo) and unlock(recNo) isn't neccesary, but as I wrote before - my interface doesn't require cookies.

in standalone mode:

delete(recNo)

in server mode:

lock(recNo)
delete(recNo)
unlock(recNo).

and I assume that every lock() must be followed by unlock(), in order to guarantee proper behaviour - it's a part of a interface's contract.

Eva, you are absolutely right about unlocking before finishing delete() operation. I've overlooked RecordNotFoundException in unlock() signature. That was my mistake.