• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

what does mean RMI cannot guarantee a client will always use the same thread in consecutive call?

 
pkinuk Buler
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I found the one of RMI disadvantages online :

RMI cannot guarantee a client will always use the same thread in consecutive call


I get confused about this point. I have two understanding of this sentence:

Supposing Client A is using Thread A to call the updateTheRecord method:



My unsderstand 1: After Thread A get the record lock, the thread link between Client A and server become Thread B. So it is Thread B to carry out the rest of the update process.

Would it be possible that Thread A gets the object lock in the updateRecord method but not finish execute all codes in updateRecord, in the moment, Thread B replaces the Thread A to run the rest of code in updateRecord() method? In this case, I think it will cause dead lock, won't it?

My unsderstand 2: The Thread A execute all codes in the updateTheRecord() method in the first call, but the Thread B replaces the Thread A to link between Client A and server when the Client A performs second time update. The third time call my be Thread C and so on....

 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi pkinuk,

It means that there is no guarantee which thread will handle consecutive calls of a client. So if you have clientA which updates a record you would have something like this:

If the lock-method is handled by thread15 on your RMI-server, there will be no guarantee that the calls to update and unlock are also handled by thread15. They could also be handled by thread15, but it is absolutely not guaranteed (and so update can be handled by thread5 and unlock by thread2).

Consequences for your assignment: if you have an interface with a lockCookie none (because you will use the lockCookie for client identification and make sure the client is owning the lock on a record before it can update/delete/unlock this record). If you don't have an interface a lockCookie (like me) you can't use the thread (and/or thread-id) to identify each client (for the reason I mentioned above)

Kind regards,
Roel
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, I'd say that you should also consider this fact in your choice of thick or thin client. For instance, if the lock method of your interface does not return a cookie value, then you can't use the Thread's ID to identify the client if you have a thick client, because the Thread that handles the second call of a client might not be the same that handled the first call. In this case, the easiest choice would be a thin client, where you just make a call, like, bookRoom() to the server, and everything is handled there. If the lock method of your interface does return a value, then you can go for a thick client, because you use the returned value to identify the client.

You know what, even if the lock method of the interface returns a value, I'd say that the easiest choice is the thin client.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic