This week's book giveaway is in the Java 8 forum.
We're giving away four copies of Java 8 in Action and have Raoul-Gabriel Urma, Mario Fusco, and Alan Mycroft on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes LockManger Issues ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "LockManger Issues ?" Watch "LockManger Issues ?" New topic
Author

LockManger Issues ?

Vikas Sood
Ranch Hand

Joined: Sep 03, 2002
Posts: 109
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
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

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


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Vikas Sood
Ranch Hand

Joined: Sep 03, 2002
Posts: 109
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
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

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
Ramesh kumaar
Ranch Hand

Joined: Mar 19, 2002
Posts: 146
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

Joined: Sep 03, 2002
Posts: 109
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
jay denzel
Ranch Hand

Joined: Sep 18, 2002
Posts: 57
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

Joined: Mar 19, 2002
Posts: 146
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

Joined: Sep 03, 2002
Posts: 109
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: LockManger Issues ?
 
Similar Threads
design comments ...
Hashtable's put method problem in locking
lock/unclock The correct question
Lockmanger- singleton implementation /static creation & assignment in RMI server ?
Platform Independent Command Line