aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes One lock call per client :-)because they don�t deserve more:-) URLyBird 1.1.3 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 "One lock call per client :-)because they don�t deserve more:-) URLyBird 1.1.3" Watch "One lock call per client :-)because they don�t deserve more:-) URLyBird 1.1.3" New topic
Author

One lock call per client :-)because they don�t deserve more:-) URLyBird 1.1.3

Mat Banik
Ranch Hand

Joined: Jan 16, 2004
Posts: 57

Hi,

My design is like this:
I have remote server factory witch is handing out remote data instances (one instance per client).
My Data has "clientHasOneLock" instance member variables:

Usage where all other exception are processed in lower layer:

My problem is that I�m not sure about the exception . It works fine, so far. I�m not getting any deadlocks.
Orphans are no problem since I�m using static WeakHashMap, unreferenced() in my remote Data object.
Each instance of remote Data is like session (one per client) and remembers clients last locked recNo and cookie.
Business logic is on the client side (have to handle lock/unlock there).

I guess this is not very clear. If you have any requests for clarification throw them in my face


SCJP 1.4 - 83%, SCJD 360-90%,
ITeezy.com
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
You're on the right track. At one point I kept the locked record in the Data object, I've since moved it into the LockManager so that I can drop in a more sophicticated LockManager without having to change the Data class. I'm not sure why you need both Unreferenced and a WeakHashMap. I prefer the Unreferenced in my RMI code, the WeakHashMap ends up requiring another thread to do the notifyAll when a client disappears.
Mat Banik
Ranch Hand

Joined: Jan 16, 2004
Posts: 57

Hi Peter,

You are right. I forgot to refactor the WeakHashMap to HashMap. :roll: �Unreferenced� works just great. About the exception, should I force the client to catch it or should I leave it as RuntimeException. I can�t see any possible recovery. Once client requests lock twice it is error in the logic witch needs to be corrected. So all �pro�s are on the RuntimeException.
What do you think?
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Matej Banik:
Hi Peter,

You are right. I forgot to refactor the WeakHashMap to HashMap. :roll: �Unreferenced� works just great. About the exception, should I force the client to catch it or should I leave it as RuntimeException. I can�t see any possible recovery. Once client requests lock twice it is error in the logic witch needs to be corrected. So all �pro�s are on the RuntimeException.
What do you think?


My booking client doesn't catch that exception, but my test client does. This lets me test the code without having to restart the test client. I do the same thing with SecurityException.
Mat Banik
Ranch Hand

Joined: Jan 16, 2004
Posts: 57

My client chatches the SecurityException, logs it and ends the VM �System.exit(-1)�.
I have other question. Do you synchronize on lock/unlock. Since I have one client per instance and he is suppose to lock just once at time I think I should be synchronized. Probably I�m missing something. It just came to my mind. Any comments?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: One lock call per client :-)because they don�t deserve more:-) URLyBird 1.1.3