aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes double lock + wait logic? 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 "double lock + wait logic?" Watch "double lock + wait logic?" New topic
Author

double lock + wait logic?

Radi Hadzhiyski
Ranch Hand

Joined: Jun 30, 2009
Posts: 47

Hi everyone,

well i thought, that i am already done with my lock and unlock, but lately i was wondering
if i am right about my design decision:

here are my requirements for the lock/unlock methods:



so my decision is:



but now i have two doubts:

1. did i violate the rule
already locked by a different client
? because
my design goes to deadlock if : lock(1) than another lock(1), until someone calls unlock(1)

2. did i violate the rule
the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked
?
because my design locks on the whole class object, witch is singleton, so when one client do something, the other have to wait. And
what is more embarrassing, when:
client A locks rec 1
then client B wants rec 1 (has to wait - no cpu cycle), but
if client c locks rec 2 and then unlocks 2
then client B checks again if rec 1 is free, if not, it goes again into wait

What do you thing?

about 1: i become a cookie value after lock, so i cannot check by the next lock, if the locked record is owner by the current thread.
about 2: i have right now no idea, how should i make it so, that only when the specific record is released, the waiting thread wakes up,
since in the book SCJD 5 from Monkhouse, they don't check if the method that wants a lock already has the lock:



So what do you thing about it.

Thanks.


SCJP 1.6 (91%), SCJD
Anne Crace
Ranch Hand

Joined: Aug 29, 2005
Posts: 223
Your code looks similar to mine except I have a while loop in my unlock not lock. I do this: See this thread for an explanation on this. While loop and 44/80 for Locking. I am doing final code checks and have some questions of my own on Locking! I think mine is pretty much correct, however. It passes several tests. Other than the while issue, your code looks good.


SCJP, SCJD
Radi Hadzhiyski
Ranch Hand

Joined: Jun 30, 2009
Posts: 47

Thanks Anne, but

the post that you gave me, didn't help me.
And you say my code seems to be ok, but

there are two things as i described it before, that are
maybe
wrong.

Is there anyone, that did it like me and passed the exam with 80/80 on lock?
Anne Crace
Ranch Hand

Joined: Aug 29, 2005
Posts: 223
For your question
1. did i violate the rule

already locked by a different client

I think the answer is no. (mine was wrong I was checking on the value, and not the record number which is utterly useless). So, thanks!
and
2. did i violate the rule

the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked

Again,I think it is no, because you didn't do anything with timeouts. That is the only thing I think that will violate that rule. Andrew's book uses them, and he is explicit that most of our assignments can't use them.
I am hoping Roel or Roberto will chime in with some feedback here, because Roel got 400/400 and Roberto aced the locking. I am very new to multi threaded coding (only this project) and other than massive searching on this forum, don't know a lot.
One question for you, are you generating the cookie from inside lock?
Radi Hadzhiyski
Ranch Hand

Joined: Jun 30, 2009
Posts: 47
yes

i have in my lock method:



but for the other doubts, that i have, i hope, that Roel or Roberto says something ;)

Bob Wheeler
Ranch Hand

Joined: Apr 24, 2009
Posts: 317
Hi Radi,

@double locking: Did you check this thread? double locking
The question is, how do we know which client is asking for the lock? I mean we are talking RMI here, at least I do. If we don't pass some informations through the network layer about the client, the client is unknown. And if we know something about the client, an unique ID, we don't need the cookie any more. I guess it is OK if we comment this in the javadoc.
Anybody agrees, disagrees?

cheers
Bob


SCJP 6 - SCJD - SCWCD 5 - SCBCD 5
JavaEnterpriseEditionFaq - TomcatFaq
Anne Crace
Ranch Hand

Joined: Aug 29, 2005
Posts: 223
Bob,
We have the cookie, so we have to use it. It gets generated based on the Record number. It actually makes identifying the client much easier If you don't have the cookie (some people don't have it), you have one more thing to figure out.
Bob Wheeler
Ranch Hand

Joined: Apr 24, 2009
Posts: 317
Anne Crace wrote:Bob,
We have the cookie, so we have to use it. It gets generated based on the Record number. It actually makes identifying the client much easier If you don't have the cookie (some people don't have it), you have one more thing to figure out.

Hi Anne,
Yeah, I like the cookies as well and I use it.
You generate your cookie based on the record number? But how does your code know that the same client has called the lock method on the same record number?

cheers
Bob
Ps. Off to bed now
Anne Crace
Ranch Hand

Joined: Aug 29, 2005
Posts: 223
Bob,

I use a static HashMap<Long recNum, Long lockCookie> and do this, as I quoted earlier above:

The cookie is unique, so there could be two record numbers (if you made a mistake and let that happen, like I almost did ) but the cookies won't match. Hope this helps.
Bob Wheeler
Ranch Hand

Joined: Apr 24, 2009
Posts: 317
Anne Crace wrote:

The cookie is unique, so there could be two record numbers (if you made a mistake and let that happen, like I almost did ) but the cookies won't match. Hope this helps.

Hi Anne,
is this code in your lock method? I have to generate the cookie in the lock method and it is unique, even if the lock method is called by the same client (One client, two calls to lock, two different cookies). So I can't check if the same client called the lock method twice. I guess, I can't use the thread id, because of RMI? Ok, I could, but wouldn't that be too much for this assignment and then what about the useless cookie?
Right now I argue in the choices.txt, that my business layer doesn't expose the lock method to the clients, so they can't do anything stupid. But because the lock method is public I have to add that also to the javadoc (like the guys in the above thread I sent).

Hope that makes sense,
cheers
Bob
Anne Crace
Ranch Hand

Joined: Aug 29, 2005
Posts: 223
Bob,
I would think checking that the record is already locked by any other client is good enough. The cookie is useful when unlocking to make sure the same client that locked the record, is the one trying to unlock it.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5407
    
  13

Hi all,

I think allowing a client to lock more than 1 record will have possibility of deadlock.

Client 1 locks first record, client 2 locks second record, client 1 locks 2nd record (and so will have to wait until client 2 releases the lock on this record) and then client 2 locks record 1 (and they all will be waiting on each other).

If you don't expose the interface-methods (and expose only some business methods, like book and find) such thing won't happen in your code, but I think your code should never deadlock (so you might lose some points in the locking section). In my solution i simply throw an IllegalStateException if a thread/client is trying to lock a record if it has already locked a record (even if he's trying to lock the same record).

Just my 2 cents.

Kind regards,
Roel


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Radi Hadzhiyski
Ranch Hand

Joined: Jun 30, 2009
Posts: 47

Hi Roel,

but how do you check if the client has already locked a record.

Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5407
    
  13

Hi Radi,

I forgot to mention that I have an interface without a lockCookie, so I had to do something on my own to identify the clients (used a setClientId-method to do that). Because I store that clientId together with the record he locked I know exactly which clients already have a record locked.

Seems to me with a lockCookie things get a bit easier: no worries about identifying the client that locked the record, no need to handle one of the drawbacks of rmi (not guaranteed that the same thread will handle consecutive requests from the same client),... But programmatically preventing the deadlock seems a bit harder (if it could be done anyway).

Kind regards,
Roel
Bob Wheeler
Ranch Hand

Joined: Apr 24, 2009
Posts: 317
Thanks for telling Roel.
I think I leave it like it is and quote in the JavaDoc, that the same client/thread is only allowed to lock records (without unlocking) in an ascending order. Of course I'll also explain that in the choices.
Is it ok, If I add some comments in the JavaDoc of the lock method (or other methods) in the interface given by Sun?

Thanks and Cheers
Bob
 
Don't get me started about those stupid light bulbs.
 
subject: double lock + wait logic?