This week's book giveaway is in the Java in General forum. We're giving away four copies of 97 Things Every Java Programmer Should Know and have Kevlin Henney & Trisha Gee on-line! See this thread for details.
hi all, I am working on the FlyByNight application. I chose the RMI approach for implementing the network protocol and my remote object extends UnicastRemoteObject. As the UnicastRemoteObject is non-replicated remote object, I was wondering how the rmiregistry handles different client request. Does the rmiregistry starts a new thread for every client request (i think so), or are we the one who should create a new thread for every request. (As you know there is a requirement for a threaded server). Can you help me with this or recommend some good rmi books that explain this issue? thanks.
I believe that the RMI Registry "lookup is synchronized, such that only one client at a time can lookup and get the instance, then when a bunch of clients each have a reference, it is only when a mehtod of that object is called that is synchronized again, just for the period of the client to run the method. In that case you do not need to spawn a thread yourself. It is handled for you there. Sun's Tutorial site has an RMI tutorial that is pretty good. Mark
it's been quite a while since i did my scjd :-)..never used RMI after that. But i have a doubt here though..
Originally posted by Mark Spritzler: then when a bunch of clients each have a reference, it is only when a mehtod of that object is called that is synchronized again, just for the period of the client to run the method. In that case you do not need to spawn a thread yourself.
Are you trying to say that all the method calls on the remote object are synchronized?
Hm... well, here's my understanding of rmi and my concern. so, the client never talks directly to the server. They communicate with each other via a stub, which is obtained from the rmiregistry. If i have just one registered remote object, RemoteData, that delegates all calls to Data and handles locking and unlocking I start worrying about performance. There is a chance a client may not obtain a lock for a very long period of time. Besides, there is the issue of changing the lock and unlock signatures and I want to avoid that. If every client has its own RemoteData, which has its own Data or share common Data, the locking becomes in a way impossible (how different remote objects will know the record on each the other’s client is working). The advantage here is that i will not care to identify the client, the server will be safe, only one client is accessing the methods. But if there are many clients there might be a lot of RemoteData instances. I am really confused. I know I am wrong somewhere and that I am missing something. There should be a solution. Any corrections, suggestions or ideas are welcome.
OK Roddy. You have one and only one Object in the Registry. It has a reference to the one and only one Data instance. A client looks up this object, calls getConnection(), it passes back a RemoteData class, one for each individual client. In the creation of this class in the getConnection method, you pass it a reference to the one and only one Data instance. Now you have each client with it's own RemoteData Object, handling the clients lock, and only one Data class for all clients, which can track all the locks by all clients, and not need to know client ID. Mark
Hi Mark, thanks again for your response and sorry for being late with mine. I started seeing the light at the end of the tunnel, though I still have some concerns about locking. I don't want my Data class to know anything about locks and locking. I am planning of having a lock manager (only one, shared by all RemoteData objects), which does the locking, but I still need a way to distinguish clients. I am planning of creating this lock manager, together with the data instance in the ConnectionManager class and passing them to the RemoteData. Then the remote data can call the LockManager passing the record number and itself as a client id. regards roddy
Nothing? Or something? Like this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!