Does anyone know if it's documented anywhere that for every connection to an RMI server their is a Thread not necissarily associated to the connection but will maintain a 1:1 relationship of connections to threads? I'm asking cause I couldn't find that documented anywhere and I'd assume you'd need that when implementing locking. Thanks, Mike
Unfortunately RMI does not guarantee that a client will always use the same thread in subsequent calls. That's why you can't 100% rely on the threadID as a clientID. However, for the most part people have posted here that they haven't seen a client use a different ThreadID, but it is documented by SUN that there is a possibility that this will happen, and you can;t rely on it. DId I just repeat myself in that last question? Sorry. So I see you are now looking down the RMI path? Good Choice. Just my opinion. Mark
Just to support Marks comments...during my testing, I noticed that RMI runtime was sometime using the same server side thread to service different client requests. I did the test by putting the first client to sleep and invoke a call from a second client. I wouldn't bet on RMI to use a unique server side thread associated to a certain client.
posted 18 years ago
Well, actually I'm trying to look for more/better reasons then the ones I have for not using RMI. I'm not neccisarilly talking about the same thread associated with connections but A thread for each connection.....so if 5 people are connected will their be for sure 5 threads to handle those client's requests? With traditional Java network programming it pretty much is guarenteed....but with the introduction of the nio classes it's not. So this is the question. Could this scenario possibly cause deadlock by using RMI? Their are 6 clients connected to the RMI server and the server has allocated 5 threads to work with these 6 connections. Deadlock could occur if the following sequence took place. 1. Client 1 locks row 1 2. Client 2 attempts to lock row 1 but waits because it's already locked. 3. Client 3 same as client 2. 4. Client 4 same as client 2. 5 Client 5 same as client 2. 6. Client 6 same as client 2. 7. Client 1 unlocks row 1. Now if 5 threads were allocated to the 6 clients then deadlock would take place because client 1 would never be able to unlock row 1 (step 7) because the 5 threads are being controlled by the other 5 clients. Does that scenario make sence? Thanks, Mike [ April 18, 2002: Message edited by: Mike Youngstrom ]
posted 18 years ago
In my testing, I have not seen such scenario. For every client request, RMI has assigned a thread in my system testing. I tested with sometime 15 simultaneous threads.
Either way it won't help in making a pro or con. Because in RMI threads for the client are all handled for you, and handled well. so that would be a pro for RMI? Once you go RMI, you'll never go back. I've got some candy Come on, you will find it easier to use RMI. I'll give you some answers, but the next ones will cost $10 a bag. OK I am just kidding here. Mark
hehe. Well, it's too late for RMI anyway. The main reason I used sockets over RMI in the first place is because I wanted to learn about the new non-blocking IO in 1.4. But I had to end that work because of the problem described above. Non-blocking IO holds no benefit if you have to have a thread for every client. So at that point it was easier to move to sockets than RMI. Oh well, I think I'm submitting my program today so. Wish me luck. If I don't pass I'll look into moving to RMI. (Even though I think my sockets and locking solution is pretty slick) Mike