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
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
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
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.
posted 17 years ago
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
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
posted 17 years ago
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
posted 17 years ago
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
You guys wanna see my fabulous new place? Or do you wanna look at this tiny ad?