• 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

LockManger Issues ?

 
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
HI Friends,
I am implementing the LockManager for my assignment at the moment.And after considerable analysis i ahve come accross these three approaches that can be followed for this purpose.They are as follows:-
1)Have my LockManager use the current thread as the client id for locking authentications.AS i have come accross a lot of posts stating that people have passed using Thread.currentThread instance as client id ,as long as they keep calls to remte methods atomic.That is we have bookSeats on server and client executes it in a single call.
2)Use a seperate Remote object assigned to each client using factory pattern as client id for locking authentications.LockManager makes use of a HashMap for holding records as keys with remote ref as values.
3)Use a seperate Remote object assigned to each client which maintains its own hashSet of records locked by that client,and also a seperate hashSet of locks maintained by the singleton LockManager containing info about all record locks.A remote object while calling unlock looks in its own hashSet a entry for that record before calling The LockManger unlock.
Which of the above three approaches serve the purpose.Kindly comment!
Thankx.
VikasSood
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
3 adds some redundancy that you won't need, it is a hybrid of how I had solved it with the LockManager.
I now really support just the LockManager and solution #2.
Mark
 
Vikas Sood
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Mark

Originally posted by Mark Spritzler:
3 adds some redundancy that you won't need, it is a hybrid of how I had solved it with the LockManager.
I now really support just the LockManager and solution #2.
Mark


As u have mentioned third option adds some redundancy, but in this case u do not need any client id for authentication as the client having the record in its own hashset will be able to call unlock on that perticular record,and as we are having seperate Remote object per client ,by implementing unreferenced interface we can still release locks which are no longer associated with a client.What do u think about it?
And also is the fist option entirely incorrect or not a proper design,even when we are having atomic methods at server end?
Thankx ,waiting for ur reply
VikasSood
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Under no circumstances does Java ever guarantee that the Thread ID will always be the same. That alone says, don't use me.
Yes #3 does not need client ID, but then you don't need LockManager then.
Mark
 
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,
If u look into the FBNspec, it says " if two clients attempts to perform the sequence lock, read, modify, unlock concurrently, then both modification attempts will be handled correctly. The AIM is to ensure that if two customers attempt to book a seat on the same flight concurrently, then the number of available seats is definitely reduced by two, unless there was only one seat, in which case, one customer will be adviced at booking time that no more seats are available".
So its very clear that there is no need to track who did lock and unlock respectively, as the lock sequence is clearly mentioned as " lock, read , modify, write, unlock". I feel its unnecessary to track the clientId in case of record locking and changing the signature of the lock and unlock method, which has not been mentioned by SUN. Seems some people are trying to confuse others by doing something unexpected and unnecessary, thus dragging the discussion on lock/unlock.
My advice is to strictly follow the spec thats given to us by SUN.
Regards,
rameshkumar.
 
Vikas Sood
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ramesh,
First thing first ,i am not trying to comfuse anybody by my posts,what i am trying to do is clear some of my doubts.
Apart from that i dont know how u can have the Data authenticity without having a client id or without using one of the above three approaches,if u can suggest any other way of doing it, or am i missing something here do let me know?
VikasSood
 
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi,
I follow ramesh approach not to track the client ID, I also think is it not necessary.
Here a link which might answer most questions.
This guy passed with 150 and did not use a client ID
Why implement more complicated issues which will not be rewarded. MHI
greets
jay
----
SCJP2
 
Ramesh kumaar
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Vikas,
Sorry I didnt pin point any one here. As per the requirement the lock is a sequence
lock(lock, read, modify, write, unlock). Here data authentication is beyond the scope of this project
who ever knows the serverIP, portno can connect and do booking.
Lets assume a condition where two clients trying to book a ticket in the same flight. I use recordNo alone to handle locking, here Iam using HashSet to hold the recNo's, Check for the existency of the recno in the HashSet inside a while loop, if the recNo does'nt exist then add the recNo to the HashSet(owning the lock). If recNo already exist then inside a I will make it to wait inside a synchronized block. As i mentoined earlier its a sequence lock so unlock() will be called by the client who own the lock earlier, which will remove the recNo, and notifyAll the waiting clients from the HashSet now the second client will own the lock and repeat the same.
Here i think this approch will fullfill the requirement that was given to as by SUN. Please correct me if iam wrong.
regards,
rameshkumar
 
Vikas Sood
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi jay,
i went through the thread,it doesnt give much info about the way the locking was implemented and also the guy lost 3-4 points on the server design and i think he didnt lose those points beacuse of using a synchronized collection.
It might have been a cae that he lost them beacuse of not having a client id implementation.
VikasSood
 
reply
    Bookmark Topic Watch Topic
  • New Topic