Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

One Last Question

 
Jim Bedenbaugh
Ranch Hand
Posts: 171
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Okay, last question and then I swear I'm going to upload. What exactly does the statement below mean?

3.2 Thread Usage in Remote Method Invocations
A method dispatched by the RMI runtime to a remote object implementation may or may not execute in a separate thread. The RMI runtime makes no guarantees with respect to mapping remote object invocations to threads. Since remote method invocation on the same remote object may execute concurrently, a remote object implementation needs to make sure its implementation is thread-safe.
[ August 24, 2002: Message edited by: Jim Bedenbaugh ]
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jim,
Just make sure that you have protected any data from concurrent modification on your remote implementations as you would in any multi-threaded environment and don't worry about that dumb spec.
If you have used a Factory and each client has a unique connection on the server, this should not be an issue at all since you have a one-to-one relationship.
Hope this helps,
Michael Morris
 
friso jonge
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,

If you have used a Factory and each client has a unique connection on the server, this should not be an issue at all since you have a one-to-one relationship

michael, i have read several postings and wondering about the factory. In my case i am using a factory on the client to decide whether i am connecting local or remote. Did you use another factory at the server ?
Also how can you find out if you have a unique connection at the server ?
In my case i synchronized the data object in the remoteObject to (hopefully) make sure it can be used multithreaded. Would that be enough. ?
regards,
friso
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Friso,

Did you use another factory at the server ?

I only had a factory on the server. That factory was bound to the RMI registry and clients connected to it thru Naming. It had a method named getConnection which returned a unique remote implementation to each calling client.


Also how can you find out if you have a unique connection at the server ?

If you use "new" in the getConnection method of the ConnectionFactory to create a remote implementation each time it is called, then the OO principal of object identity assures us that the connection is unique.

In my case i synchronized the data object in the remoteObject to (hopefully) make sure it can be used multithreaded. Would that be enough. ?

Probably not. Most of the methods in Data that are in peril of concurrent modification are already synchronized, so synchronizing the data object won't guarantee thread safety. The main area you need to concentrate on is in locking and unlocking. That's where the greatest danger of concurrent modification exists. There are others though, so take a close look at any method in any class that might have more than one thread running in it and changes the state of the object.
Hope this helps,
Michael Morris
 
friso dejonge
Ranch Hand
Posts: 162
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi michael,

I only had a factory on the server. That factory was bound to the RMI registry and clients connected to it thru Naming. It had a method named getConnection which returned a unique remote implementation to each calling client.

This means code which is something like:

where did you implement that method ?
I implemented this in the starting of the server. So everyone has the same RemoteDataObject. Works without a problem. (my locking mechanism works on basis of getClientHost so it does not need a unique clientID in form of remotedataobject)
Could there be any obejction against everyone having the same object ?
regards, friso
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

where did you implement that method ?

On the server in my ConnectionFactory implementation. My method returned a different object to each client.

... So everyone has the same RemoteDataObject. Works without a problem. (my locking mechanism works on basis of getClientHost so it does not need a unique clientID in form of remotedataobject)
Could there be any obejction against everyone having the same object ?

As long as your testing shows that it works I suppose it is OK. Here are some potential problems:
  • Poor performance since every client is making calls on the same object.
  • Greater chance of data corruption for the same reason listed above. You must be very careful about synchronizing methods on this object.
  • Using getClientHost is not a truly deterministic way of IDing clients. Two clients could connect from the same desktop or serveral clients could be behind a firewall or NAT server and have the same IDs as far as the server is concerned.


  • Hope this helps,
    Michael Morris
    [ August 27, 2002: Message edited by: Michael Morris ]
     
    friso dejonge
    Ranch Hand
    Posts: 162
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    thank michael,
    you may be right about the reasons, but i looked at the sun tutorial and they are doing exactly the same. they only have one instance as far as i can see.
    so your client calls getconnection on the stub which returns a new instance of the remoteobject, am i right.? After that you use that object to call on the Data.
    Is this a factory design pattern ?
    thanks, friso
     
    Michael Morris
    Ranch Hand
    Posts: 3451
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    so your client calls getconnection on the stub which returns a new instance of the remoteobject, am i right.? After that you use that object to call on the Data.
    Is this a factory design pattern ?

    That's it, except that I actually only make calls on the interface from the client, but the remote object has a reference to the Data object and passes those calls on to Data. That is one implementation of a factory pattern. Many times a factory pattern is used to return platform-specific concrete class instances that have an abstract API. There are also many other uses for it as well.
    Let me say, that if you feel comfortable with what you have done and it works, don't let my opinions dissuade or discourage you from sticking with it. I do feel that a Factory is probably the best way to handle client connections in this situation though for the reasons I listed. Once again though, if you can adequately defend your design and are convinced it is thread safe you should be fine.
    Hope this helps,
    Michael Morris
     
    Mark Spritzler
    ranger
    Sheriff
    Posts: 17278
    6
    IntelliJ IDE Mac Spring
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Topic: One Last Question

    Ok, I think we will hold you to that.
    Mark
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic