RMI Multi-Threading/Security

[Daniel Simpson]

I finished my RMI networking today, and finishing up the final touches on my assignment. I am new to RMI (as of yesterday ) and I wanted to hear and get some ideas about how others approached multi-threading/concurrent access. All of my methods are synchronized in my Data class. Is this sufficient enough? Also, I had another question. Before when I was planning on doing sockets, I had a HashMap in my LockManager that first checked to make sure that the current thread did not already hold a lock. Should I still keep this in my implementation for when the assessor runs different lock tests aside from testing my server? I realize that the HashMap is pointless for RMI because there's no guarantee on threading, but is it worth keeping for preventing deadlocking in other tests? Or is there a way I can have a HashMap with client id's or something along the lines of that? I appreciate everyone's help lately to all of my questions. This place has saved my butt.

[peter wooster]

With RMI you probably have an object per client on the server. This object can be the key to your HashMap. If you use an object per command on the server you will need to have some sort of session id that identifies the clients.

[Daniel Simpson]

Originally posted by peter wooster:
With RMI you probably have an object per client on the server. This object can be the key to your HashMap. If you use an object per command on the server you will need to have some sort of session id that identifies the clients.

Object per client on the server referring to this in my code?:

public static DataAdapter getRemote(String ip, String port) 
            throws RemoteException {
        try {   
            return (DataAdapter) Naming.lookup(
                "rmi://" + ip + ":" + port + "/Bodgitt&Scarper");
        } catch (Exception ex) {
            throw new RemoteException("Unable to return a remote adapter: "
                + ex.getMessage());
        }

I'm still not understanding how this solves the deadlocking issue. This may sound like an extremely stupid question but threads are executing the synchronized code, not client objects. I guess the concept isn't making sense to me right now. Are the client objects and its own thread/threads somehow related? (Like setting the name of the thread to client object?) What about my other question regarding the use of a HashMap with thread names to prevent deadlocking. Should I keep that in anticipation of other threading tests the assessor might run. I appreciate all of the help, sorry I'm not understanding the concept.

[Daniel Simpson]

I've read some posts about client id's in RMI, including using java.rmi.server.UID. Would I create a new UID() in the contructor of my remote object? Also, how would I pass that UID into the locking methods? Would I set the thread name to the UID? Lastly, would synchronizing my methods on the server be sufficient enough? Thanks.

[Andrew Monkhouse]

Hi Daniel,

I am not sure where you are going with the UID concept. If I am understanding you correctly, your lock method cannot be used unless you are using RMI. Normally you would want to re-use as much code as possible for both networked and standalone versions, but if your lock code is reliant on RMI, then your standalone version cannot use it. I think this will not be allowable according to the SCJD instructions.

Peter, I suspect, was talking about creating a new instance of the Data class per connection. At present you probably have a Proxy class which you are binding to the RMI registry, and every client connects to the same Proxy. The alternative is to have a Factory class that will create a new Proxy for each client.

If you have a unique instance of the Data class for each connected client then you can use that instance as your lock owner identifier. In addition, you have the potential to use either RMI's Unreferenced interface or a WeakHashMap to handle orphaned locks (if you decide to handle them).

Regards, Andrew

[Daniel Simpson]

Originally posted by Andrew Monkhouse:
Hi Daniel,

I am not sure where you are going with the UID concept. If I am understanding you correctly, your lock method cannot be used unless you are using RMI. Normally you would want to re-use as much code as possible for both networked and standalone versions, but if your lock code is reliant on RMI, then your standalone version cannot use it. I think this will not be allowable according to the SCJD instructions.

Peter, I suspect, was talking about creating a new instance of the Data class per connection. At present you probably have a Proxy class which you are binding to the RMI registry, and every client connects to the same Proxy. The alternative is to have a Factory class that will create a new Proxy for each client.

If you have a unique instance of the Data class for each connected client then you can use that instance as your lock owner identifier. In addition, you have the potential to use either RMI's Unreferenced interface or a WeakHashMap to handle orphaned locks (if you decide to handle them).

Regards, Andrew

Okay, Andrew, that clears up a lot of stuff! I am using a proxy, and every client shares one instance of Data. I don't want my lock method to be dependent on RMI because I use it for local too. Because my Data is a singleton, would synchronized methods be sufficient enough for locking in remote? I am keeping my hashmap of thread names, but i can document that it won't apply to RMI. Yeah, they will be used in RMI but will be of no use, only for local. What do you think?
[ January 16, 2005: Message edited by: Daniel Simpson ]

[Andrew Monkhouse]

Hi Daniel,

I am keeping my hashmap of thread names, but i can document that it won't apply to RMI.

What will be the benefit of keeping the hashmap of thread names if it does not apply to your networked solution?

When you are documenting why you are tracking the thread names, you will need to be explicitly clear that you understand why they cannot be used for RMI. I would suggest that such documentation would need to be in both your design decisions document, and in the source code itself.

You may even find that, if there is no outstanding benefit to tracking thread names in standalone mode, you may be better off removing the potential for confusion by removing the tracking of thread names.

Regards, Andrew

[Daniel Simpson]

Originally posted by Andrew Monkhouse:
Hi Daniel,



What will be the benefit of keeping the hashmap of thread names if it does not apply to your networked solution?

When you are documenting why you are tracking the thread names, you will need to be explicitly clear that you understand why they cannot be used for RMI. I would suggest that such documentation would need to be in both your design decisions document, and in the source code itself.

You may even find that, if there is no outstanding benefit to tracking thread names in standalone mode, you may be better off removing the potential for confusion by removing the tracking of thread names.

Regards, Andrew

Hey Andrew, I documented that in my design.txt that this would be beneficial in standalone but not in RMI. Here's a question (actually two ):
1) Is the sychronization of methods sufficient enough in RMI to prevent threading deadlock or other thread problems (excluding orphan locks)?
2) If I should not use a thread name hash map for local, how will I be able to prevent the assessor from running tests such as a thread trying this:

lock c  = data.lock(0);
      lock cc = data.lock(0); 

The above code will result in a deadlock as the thread waits for eternity for itself to unlock. Since I am using a shared proxy, the client identification by use of instance is of no use in this case, and I don't want to make my locking solution depedent on one and not the other? Is it possible in my case to reach some sort of middle ground? A combination of a thread hash map and synchronized methods? Synchronized methods being beneficial in RMI threading yet overhead in local, and a thread hash manager being beneficial in local yet of no concern in RMI? What do you think? Feel free to rip it apart, I greatly appreciate your ideas/help. Thanks!

[Andrew Monkhouse]

Hi Daniel,

1) Is the sychronization of methods sufficient enough in RMI to prevent threading deadlock or other thread problems (excluding orphan locks)?

That is difficult to answer because the question is so generic.

In your case, where I believe you are talking about synchronising methods in the Data class only, and your Data class is a Singleton, then you should be safe.

As soon as you start talking about any other synchronization (such as having a synchronized block using the RandomAccessFile object as the mutex) within your Data class, or having synchronization in other classes / instances of Data class, then all bets are off.

Also note that you mentioned deadlock in your question, which in context I have taken to mean thread deadlock not logical record deadlock which I am addressing in the next question.

2) If I should not use a thread name hash map for local, how will I be able to prevent the assessor from running tests such as a thread trying [example shown above]

Does this imply that you are preventing logical record deadlocks from multiple clients in RMI? That is (reusing your example) if client A requests a lock for record 0 then requests it again you will somehow handle the second request? Or a more complex example: client A requests a lock on record 0, client B requests a lock on record 1, client A requests a lock on record 1, client B requests a lock on record 0?

Regards, Andrew

[Daniel Simpson]

Originally posted by Andrew Monkhouse:
Hi Daniel,

That is difficult to answer because the question is so generic.

In your case, where I believe you are talking about synchronising methods in the Data class only, and your Data class is a Singleton, then you should be safe.

As soon as you start talking about any other synchronization (such as having a synchronized block using the RandomAccessFile object as the mutex) within your Data class, or having synchronization in other classes / instances of Data class, then all bets are off.

Also note that you mentioned deadlock in your question, which in context I have taken to mean thread deadlock not logical record deadlock which I am addressing in the next question.

Does this imply that you are preventing logical record deadlocks from multiple clients in RMI? That is (reusing your example) if client A requests a lock for record 0 then requests it again you will somehow handle the second request? Or a more complex example: client A requests a lock on record 0, client B requests a lock on record 1, client A requests a lock on record 1, client B requests a lock on record 0?

Regards, Andrew

Hey Andrew,

1) Yes, I am using a single instance of Data that all the proxies share. I synchronized the methods in my Data class, but no where else, and I didn't use any sync blocks.
2) Yes, I am referring to logical record locking and preventing record deadlock. Actually, I have a cookie hash, so if client A locks record 0 and client B tries to lock record 0, B will wait until A has unlocked. The thread manager hash map will make sure a certain thread doesn't already hold a lock. So things such as client A locks record 0, client A tries to lock record 0 while alreading have locked 0. Or client locks record 0, client A tries to lock record 1, too. Basically prevents clients from locking their own record again or locking multiple records while already holding a lock on a record. When the client calls unlock on the record its holding, the cookie is removed and the thread is removed from the thread manager hash map.