• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

double lock + wait logic?

 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Radi Hadzhiyski
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
yes

i have in my lock method:



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

 
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Anne Crace
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Radi Hadzhiyski
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Hi Roel,

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

 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Look! I laid an egg! Why does it smell like that? Tiny ad, does this smell weird to you?
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic