Keith Wheeles

Greenhorn
+ Follow
since Feb 21, 2001
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Keith Wheeles

Here is my rebind code:
String name = "dataserver";
Naming.rebind(name, remoteData);
remoteData is instance of my class implementing the RMI remote interface.
Here is my lookup code:
String name = "rmi://"; + host + "/dataserver";
db = (RemoteDataInterface) Naming.lookup(name);
host is:
* @paramString hostDNS name or dotted quad string of remote machine
*running database server.
Luis:
I spent a LOT of time on this and ended up scrapping the idea. I put the recNum of each locked record in a Hashtable. Integer(recNum) was the key, the value was an object to synchronize on. This would work OK if not for the database level lock (recNum == -1).
I found I needed to notify on the following three conditions -
1.) record unlocked (pulling the object out of Hashtable).
2.) database unlocked (with a special object for that).
3.) record lock Hashtable becomes empty (in case waiting for database level lock).
I built a multi-threaded testbed to run against this approach (synchronizing against record specific objects) and found that the lower level synchronizing could result in error ocnditions.
I ended up synchronizing the lock and unlock methods and using instance variables (objects) within the Data class - the objects are much like what I'm describing above.
Unless I relaxed some of my working assumptions (i.e., that a database level lock request would block on both existing database level lock AND on non-empty list of locked records) I was unable to get this work. The code was also a bit convoluted and unappealing.
Thanks,
Keith
Ajit -
The thread goes into a wait properly, so it can't run the notify method to wake itself up. The notifyAll would need to be in another thread in order to wake this one up.
Keith
You lose the monitor (synchronization) on the obj when you call wait. The code above will throw an IllegalMonitorState exception when you call notifyAll because you no longer have the Monitor. Before calling notify you need to get the monitor again (synchronize on the obj).
If you implement a book method that is synchronized across lock, write, unlock - you no longer need to worry about the lower level synchronization in your test prototype. I would not personally do the book method synchronized across all of those because of the assignment requirement that all public methods of Data be shown by the client. The synchronized book method within Data would be fine, but now if the client relies on the lock, modify, and unlock methods (which are public) they don't have the right functionality separate from the book method.
Keith
Assignment - "You must create a data server that will accept multiple concurrent network connections and allow them to interrogate and manipulate the database. Because multiple concurrent connections may exist, you must make both your server and the suncertify.db classes threadsafe. You may implement your threaded server in more than one class if you choose."
However, if you choose RMI it appears RMI will handle the concurrency - the client simply calls the Data methods through an object which: a.) implements the remote interface required by RMI, and b.) includes all public methods of Data. So, if you use RMI, do you even need to worry about creating and managing threads?
Thanks,
Keith