wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes One Last Question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "One Last Question " Watch "One Last Question " New topic
Author

One Last Question

Jim Bedenbaugh
Ranch Hand

Joined: Nov 09, 2001
Posts: 171
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 ]

Regards,
Jim
SCJP, SCJD, SCWCD, SCEA Part I
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
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


Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
friso jonge
Ranch Hand

Joined: Aug 06, 2002
Posts: 41
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

Joined: Jan 30, 2002
Posts: 3451
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

Joined: Jul 11, 2002
Posts: 162
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


swimming certificate (A & B), shoelaces diploma, and some useless java ones.
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451

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

    Joined: Jul 11, 2002
    Posts: 162
    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

    Joined: Jan 30, 2002
    Posts: 3451

    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

    Joined: Feb 05, 2001
    Posts: 17249
        
        6

    Topic: One Last Question

    Ok, I think we will hold you to that.
    Mark


    Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
    How to Ask Questions the Smart Way FAQ
     
    wood burning stoves
     
    subject: One Last Question
     
    Similar Threads
    RMI Server
    HELP: Muilt-Threaded Server
    Is RMI Thread Safe?
    RMI and multithreading
    NX: RMI and Mutlithreading