• 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

How to use lock cookie to identify a client?

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have been trying to figure out how to use lock cookie to identify a client.

The interface for my project is as following:



From the lock method's definition, I believe that the returned lock cookie is to be used to identify the client that is trying to access the record.

I reckon from the previous posts that some people come out with a hashmap <Long, Long>; , with key = recNum, value = cookie.
This is useful to check whether a record (identified by the record number) is locked or not by checking if the record number is in the hashmap, but it won't tell the record is locked by which client, since the client doesn't has a way to store the lock cookie in its class member (remember! we are not allowed to modify the given interface).

One solution that I know is by implementing a connection factory, so every generated client (in networked mode, it doesn't really matter in stand alone mode) is unique.
However, this will render the lock cookie useless, since I can just create a hashmap <Long, DB>; where the key is the record number & the value is the client itself.

Any ideas people?
 
Ranch Hand
Posts: 192
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Yudiman

If you do the processing within the context of a single method then your client will still have the cookie in the calling method. So for example in your book method lif you do lock/process/unlock then the cookie you locked with will still be current for this particular client.

If you use a locking map of contractor record numbers and a long for the cookie then no other client can get at this particular record number once it
is locked in the map. Once you have the lock you can then process and unlock and remove this record number from the locking map.

Cheers Kevin.
 
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I use the recNo to generate the cookie. I then put both the recNo and the cookie in Map of locked records. I suggest you do a search on "lock cookie". You will find lots of ways to implement this.
 
Yudiman Kwanmas
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To Anne Crace
Yes, that's what I did. I created a static hashmap<recNum, cookie>.

To Kevin Florish
I've been trying to digest your answer, but I'm still confused. My main question is how do I associate the cookie to a particular client, if other client is trying to access a particular record number that has already been exist in the static hashmap (means it has been locked)?

By the way of illustration,

1) Client A wants to update record number 1.
2) Client A checks the static hashmap, and apparently record number 1 doesn't exist in the hashmap. It means recNum 1 is free.
3) Client A calls lock method to lock the record. It will add recNum 1 to the hashmap, together with the generated cookie. The lock method also returns the lock cookie as its output.
4) the returned lock cookie will be passed to the method as specified by this method declaration:



Question 1 : Now why do we have to pass the lock cookie into the update method? How the update method should handle the lock cookie inside its method definition?

5) Meanwhile, Client B wants to update record number 1 as well.
6) Client B checks the static hashmap, and find out that the record number is mapped . It means the record number is locked. (At this point, we don't need the lock cookie yet, since we can use hashmap.containsKey(Object key)).
7) Then client B has to determine which client is locking the record with recNum 1. Because if it's client B which is locking the record, then Client B will not need to wait until the record is unlocked. However if other client is locking the record, then I believe the lock cookie comes into use.

Question 2 : How client B knows that the lock cookie belongs to a Client others that Client B (in this case Client A). Based on my illustration, Client B hasn't generated a lock cookie yet. Even if it had,
then how client B store the cookie in its member so it can be compared with the cookie in the hashmap?

ps: using this approach means that in the unlock method, the entry with the associated record number must be removed from the static hashmap to indicate the record is now free.

ps2: from my illustration, I assume that a lock cookie is associated to a particular client. So if there are 5 clients trying to update a record, then 5 cookie values will be generated. Is my assumption correct?
 
Kevin Florish
Ranch Hand
Posts: 192
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Question 1 : Now why do we have to pass the lock cookie into the update method? How the update method should handle the lock cookie inside its method definition?


Cookie is passed into update to ensure its the same cookie we locked the record with, if not throw a security exception.


5) Meanwhile, Client B wants to update record number 1 as well.
6) Client B checks the static hashmap, and find out that the record number is mapped . It means the record number is locked. (At this point, we don't need the lock cookie yet, since we can use hashmap.containsKey(Object key)).
7) Then client B has to determine which client is locking the record with recNum 1. Because if it's client B which is locking the record, then Client B will not need to wait until the record is unlocked. However if other client is locking the record, then I believe the lock cookie comes into use.


5 & 6) Client B should sit there waiting for a signal when the lock is released in the unlock method.
7) Not sure what you mean here? Client B doesn't have to have any knowledge of which client is holding the lock, just that its in a waiting state.


Question 2 : How client B knows that the lock cookie belongs to a Client others that Client B (in this case Client A). Based on my illustration, Client B hasn't generated a lock cookie yet. Even if it had,
then how client B store the cookie in its member so it can be compared with the cookie in the hashmap?


Let me try to give you an example:
Client A locks record and creates a cookie.
Client B tries to lock record, its already in locking map, so it waits.
Client A updates the record using the cookie it generated.
Client A releases its lock, once again checking cookie created when it locked the record and signals all waiting threads after removing the record number from the locking map.
Client B or another client now hads access to this record number.

Client B gets priority: locks, updates, unlocks.

The winning thread will lock, process and unlock before any other threads can use the record number. Clients dont need to have any knowledge of other clients.

ps: using this approach means that in the unlock method, the entry with the associated record number must be removed from the static hashmap to indicate the record is now free.


Yes and awaiting threads need to be signalled.


ps2: from my illustration, I assume that a lock cookie is associated to a particular client. So if there are 5 clients trying to update a record, then 5 cookie values will be generated. Is my assumption correct?


Yes each client will create its own unique cookie each time it does a process.

Hope this helps.





 
Yudiman Kwanmas
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Kevin, it becomes clearer now.

But now I am confused with the SecurityException. The spec says that security exception is thrown if the record is locked with a cookie other than lock cookie. It means that in the process method, lock cookie must be compared with a value type long, and both must have same value.

My question is from where the process method can get that value ?

And if I came out with this theoretical approach:



Would the concurrency still work fine? This is my 2nd question.

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

But now I am confused with the SecurityException. The spec says that security exception is thrown if the record is locked with a cookie other than lock cookie. It means that in the process method, lock cookie must be compared with a value type long, and both must have same value.



Remember if you are doing lock/process/unlock within the context of a single method call; from the Booking() method:

Get a cookie (long) for your lock method
Lock with this cookie (put record number and this cookie in the locking map)
Process using this cookie (compare this cookie with cookie in the locking map)
Unlock using this cookie (compare this cookie with cookie in the locking map)

The SecurityException is there to ensure that the cookie you locked with initially and put in the locking map is still the same when you process and unlock. If the cookie in the map has changed it probably means your locking isn't working correctly as no other process (thread) should be able to change the locking map while it is locked.
 
Yudiman Kwanmas
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I see, I think now I understand what you mean.

Thanks a lot Kevin.

Cheers,

Yudiman
 
reply
    Bookmark Topic Watch Topic
  • New Topic