aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Lock  design  comments Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Lock  design  comments" Watch "Lock  design  comments" New topic
Author

Lock design comments

Juan Katabasis
Ranch Hand

Joined: Jun 20, 2001
Posts: 46
Hello friends
I am finishing my fbn projec, just need to implement the lock mechanism. I have read many messages on this forum (you all guys are great) which have helped me lot to reforce my ideas on some points, criticize on others, and understand blurred ones.
To implement locking without modify the lock - unlock signatures in Data i am planning to use in my RemoteData (which maps request to Data) a HashSet to check the lock requests in queue the Client has. This way each RemoteData from every Client checks its own request and needs to invoke just a lock( int recnum ).

public class RemoteData extends UnicastRemoteObject implements IRemoteData {
private Set lockedRecs;
...
public void lock(int record) throws DatabaseException, RemoteException {
if (! verifyLock(record) ){
throw new DatabaseException(" A request on this flight is still being processed");
}
lockabledb.lock(record);
}
....
private boolean verifyLock( int recnum){
return lockedRecs.add(new Integer(recnum));
}
(lockabledb is the working instance of a subclass of Data in server)
I like simplicity so this seems a nice solution to me, but i don�t like of this possibility the fact that i am implementing the logic for record locking in two separate classes (RemoteData and LockManager). Also i am not completly sure if this kind of solution is according to Sun requeriments, as most of the logic of the lock mechanism will NOT be in the lock - unlock method of the provided class Data.
Do you think that solution is acceptable? Any comment please?
[ October 07, 2002: Message edited by: Jaun Katabasis ]

Regards<br />J.
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

I like simplicity so this seems a nice solution to me

Your solution is too simple to work. In your implementation, if the record is locked, an exception is thrown, and (presumably) the client is denied the booking. Instead, your thread shoud wait() until it is notify()ed that the record was unlock()ed. Also, with your implementation of a simple HashSet holding the locks, how do you plan to satisfy the requirement that client A should not be allowed to unlock() a record that was lock()ed by clent B? Remember that the collection of locks should be shared by all clients.
Eugene.
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Juan,
I Often find myself agree with Eugene, but not in this case. I find your solution elegent and well thought out: nicely done. Just remember to make the structure static, so that it(the set/map/whatever you use) is, in fact, shared by all objects of the class.
All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ October 09, 2002: Message edited by: Max Habibi ]

Java Regular Expressions
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

I oftend find myself agree with Eugene, but not in this case.

I read the original post more carefully, and I realized that the code for locking that Jaun included was only first part of it, the second lock() implementation is in the lock manager, of course. So I will take my previous comment back, -- yes, your solution will work. In fact, that's what I had in one of my designs, but I didn't like it for the same reason as you, -- two implementations of the lock() method, so I settled for an alternative design.
Eugene.
[ October 08, 2002: Message edited by: Eugene Kononov ]
Juan Katabasis
Ranch Hand

Joined: Jun 20, 2001
Posts: 46
thanks for your reading and notes Max and Eugene
Eugene: you are right, this is just part of the complete mechanism, but i am finding it simplifies extremly the general lock mechanism(i'll try to argue this now) and respects sun requeriments on signatures
Max: each client has only one RemoteData wich contains the HashSet, so each RemoteData takes care just of the own requests from the Client it belongs to. why do you think it should be static?
it's a question of responsabilities. in these two situations:
A - a client should not request a lock over the same record twice
B - a client should not unlock a record locked by a different client
i think they are not part of the main lock mechanism but yes part of the 'right behaviour' of a client, so i tend to interpretate these two cases as part of a client own responsabilities, having sense that for a given client an object binded to it (as RemoteData) takes care of these two situations.
if that is aceptable, the general lock mechanism in LockManager will also be extremly simple, using just also a HashSet and accepting any lock -unlock order
so RemoteData can be as
(not yet finished)

as each client owns an only RemoteData object, it's not needed to take care here about threads.
i find it a good solution, but just need to reforce my argumentation on responsabilities.
comments, please?
[ October 09, 2002: Message edited by: Jaun Katabasis ]
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Juan,
Your implementation is different then I expected to be: to be honest, I'm not sure it will work. Have you tried a test client that spawns, say, a 100 threads that try to use your object concurrently?
Some thoughts:
The code in you locking code isn't synchronized on anything, so it's not atomic(even if it's a single line of code). Say both clients A and B want to lock record #2. Client A checks to see if record @2 is locked. It currently isn't, so A tries to lock record # 2. But A get switched out(because it's thread got switched out). Now client B could check to see if record #2 is locked: it isn't, because A's not done. So B actually succeed in locking record #2. B finishes, and A wakes up again Now, because A has no way of knowing that record #2 has been locked while A's thread was napping(remember, you're past the if statement now), A goes ahead and locks record #2, effectively hijacking it from B. See the problem?
You're on the right track, there is an elegant solution here, but I don't this particular implantation is there yet. For a complete path on this, try thumbing through chapter 4 of my book.
All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
Salish Tankard
Greenhorn

Joined: Oct 08, 2002
Posts: 8
Some thoughts:
The code in you locking code isn't synchronized on anything, so it's not atomic(even if it's a single line of code). Say both clients A and B want to lock record #2. Client A checks to see if record @2 is locked. It currently isn't, so A tries to lock record # 2. But A get switched out(because it's thread got switched out). Now client B could check to see if record #2 is locked: it isn't, because A's not done. So B actually succeed in locking record #2. B finishes, and A wakes up again Now, because A has no way of knowing that record #2 has been locked while A's thread was napping(remember, you're past the if statement now), A goes ahead and locks record #2, effectively hijacking it from B. See the problem?


Hi Max,
Would it work if I synchronize the record number object (a Vector or a SortedSet)? By doing this, there is only one client can access this object at a time. What about two clients approach the object at the SAME point (rare situation, but possible?), who will get the object? How should I take care of this situation? Thank you
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Originally posted by Salish Tankard:


Hi Max,
Would it work if I synchronize the record number object (a Vector or a SortedSet)? By doing this, there is only one client can access this object at a time. What about two clients approach the object at the SAME point (rare situation, but possible?), who will get the object? How should I take care of this situation? Thank you

This brings us back to the static member variable. Say your Set/ArrayList/Hashmap is static and you synchronize on it in the lock/unlock methods. This address both of your issues, including two concurrent clients: One or another will achieve a lock on the structure, and the other client will wait. Then, when first client releases the lock and the second client finally achieves it, that second client will see that the record has already been claimed.
Also, you (almost)always want to use a while statement in your threading code, not an if statement.
Finally, if your clever and you use a map, then you can store the ID of the locking Thread(or the Thread itself). This opens the door to addressing Eugene's (valid) concern about making sure that Client A can't unlock a record that client B locked.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
Juan Katabasis
Ranch Hand

Joined: Jun 20, 2001
Posts: 46
Each client has only one RemoteData, and each RemoteData has its own HashSet to get track of that Client's own lock requests, so there is a HashSet for each client for this part.
Once the RemoteData verifies the Client is trying to lock a record he didn�t ask for before (a record which is not in his HashSet) , or unlockocking a record which he asked for before (whose number is in that HashSet), he will proced to a lock(record) over LockManager.
My arguments are just in the RemoteData part, ensuring a 'good behaviour' from each client, but not in LockManager.
While writing this, i notice what i am forgetting here i think is to use one thread for every order request, ( i see now your 'static' comment ) and making the 'good behaviour' check system thread safe in RemoteData.
[ October 09, 2002: Message edited by: Jaun Katabasis ]
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Juan,
This approach seems a overly complex to me: you're keeping multiple hashmaps, one for each client, and you're parsing those hashmaps. are you creating these, one per client, or are you using a nested structure, like a Vector of maps? Also, you're speading locking out over several objects. It seems like you've created a complex structure to mimic tools that Java already provides for free. I would suggest a simpler approach: one static ArrayList/Hashmap object in the Data class, and a RemoteData object per client, each RemoteData has it's own copy of a Data. Inside of Data, Synchronize on the static structure to lock and unlock.

good luck.
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

I would suggest a simpler approach: one static ArrayList/Hashmap object in the Data class.

In my opinion, this will make the responsibilities of Data class too broad. The purpose of the Data is to describe the database and provide the interface to manipulate the data. The record locking (in whatever form it is implemented) should be encapsulated in a separate class, and no references to lock collections should be present in the Data class.
Eugene.
Juan Katabasis
Ranch Hand

Joined: Jun 20, 2001
Posts: 46
thanks for your point of view friends
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Originally posted by Eugene Kononov:

In my opinion, this will make the responsibilities of Data class too broad. The purpose of the Data is to describe the database and provide the interface to manipulate the data.
Eugene.


I disagree Eugene. I think Sun wanted you to use the Data class to lock and unlock. IMO, that's why they provided lock/unlock method signatures. You can step around that, and depending on the assessor, you might be ok. But, IMO, you're taking a risk. I advocate sticking to the letter of the design, as it was presented.
Just because you're coloring inside the lines, it doesn't mean you're not an artist .
all best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ October 09, 2002: Message edited by: Max Habibi ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Lock design comments
 
Similar Threads
FBN: changing lock method's IOException
FBNS: Final locking architecture, comment please...
Locking in modify method?
lock/unlock
FBN Design Doubts Please Help!!