wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes My lock method 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 "My lock method" Watch "My lock method" New topic
Author

My lock method

mohamed sulibi
Ranch Hand

Joined: Sep 04, 2005
Posts: 169
Dears;

please help me, this is my lock method implementation:

....
try{


please help me as you see i don't pass an instance of dbHandler that wrap the file access to lockHandler. my reason of this is to decrease the association between these
classes. but now i think the lockHander must have an instance of dbHandler to check if the record exist or not on the synchronized block.

also i see now that the lock method may be throw the record not found exception also after he locked the record is it ok ?

or i have to delete the last check or i must pass an instance of dbHandler to lockHandler.


please give me your help.


best regards.
SCJP, SCJD ... in progress ( from 1/8/2007 till now)

mohamed sulibi
Ranch Hand

Joined: Sep 04, 2005
Posts: 169
dear;

now i modified my method as:



what you think ?

regards.
Fola Fadairo
Ranch Hand

Joined: Feb 16, 2004
Posts: 35
1) If the record does not exist, why does it have to be unlocked?
2) What are you doing about this
If the specified record is already locked by a different client, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked.


The following steps should be fine

Step 1) check if record exists
(a) if record exists, go to next step
(b) if record does not exist, throw exception
Step 2) check if record is locked by another client
(a) if record is locked by another client, give up the CPU and consume no CPU cycles until the record is unlocked.
(b) if record is not locked by another client, go to next step
Step 3) lock the record

Search for "lock method" on the forum, there are very many extensive descriptions on the topic. In my opinion, the old posts on this topic are the best.

Regards.
Alecsandru Cocarla
Ranch Hand

Joined: Feb 29, 2008
Posts: 158
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().


SCJP 1.4 100%
SCJD 99.5%
mohamed sulibi
Ranch Hand

Joined: Sep 04, 2005
Posts: 169
dear;

so Alecsandru you suggest that :



and when the user read or update or delete the record the methods will throw exception so unlock the record normally.
so does the following statement is must : "when the client lock the record properly he will not see any recordNotFound exception from any methods he used
instead of unlock" is this a mandatory requirement or not ?

regards.
Alecsandru Cocarla
Ranch Hand

Joined: Feb 29, 2008
Posts: 158
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.
mohamed sulibi
Ranch Hand

Joined: Sep 04, 2005
Posts: 169
dear;

Do you have this statement inside your requirements?


actually No, i don't have this statement in my requirements, but i ask you if it is implicitly stated.

If your update and delete methods throw RNFE". Do you have RNFE in your update() and delete() methods declaration?


Yes. my delete and update throw RNFE.

regards.
Alecsandru Cocarla
Ranch Hand

Joined: Feb 29, 2008
Posts: 158
your interface says update and delete can throw RNFE, so how can it be implicitly stated that they shouldn't?
 
GeeCON Prague 2014
 
subject: My lock method