java RMI and synchronization

[guest_user]

if I have a remote object that extends UnicastRemoteObject and there are 2 or more processes which call the remote object's methods, how do I prevent race conditions, inconsistency issues, etc when the 2 or more processes call the same method at the same time?

[JosAH]

if I have a remote object that extends UnicastRemoteObject and there are 2 or more processes which call the remote object's methods, how do I prevent race conditions, inconsistency issues, etc when the 2 or more processes call the same method at the same time?

You'd do it the same as you would do with local methods: synchronize them, synchronization isn't part of the interface definition (it's an 'implementation detail').

kind regards,

Jos

[guest_user]

You'd do it the same as you would do with local methods: synchronize them, synchronization isn't part of the interface definition (it's an 'implementation detail').

kind regards,

Jos

but isn't synchronization using the 'synchronized' keyword for threads? in this case there would be 2 client JVMs(processes) and 1 server JVM(processes)

[JosAH]

but isn't synchronization using the 'synchronized' keyword for threads? in this case there would be 2 client JVMs(processes) and 1 server JVM(processes)

True, but if two client objects C1 and C2 refer to the same server object S1 and methods are synchronized in object S1 the two Threads started (indirectly) by objects C1 and C2 are executed synchronized i.e. in a mutual exclusive mode.

[guest_user]

True, but if two client objects C1 and C2 refer to the same server object S1 and methods are synchronized in object S1 the two Threads started (indirectly) by objects C1 and C2 are executed synchronized i.e. in a mutual exclusive mode.

so java rmi spawns individual threads on the server end based on each client call?

[JosAH]

so java rmi spawns individual threads on the server end based on each client call?

It has to if it wants the remote object to act transparently as if it were a local object. Of course it uses Executors and Futures and minimizes the resources needed by those Threads.

kind regards,

Jos

[guest_user]

if my remote object has a login(), logout() and a doWork() method and I want each client to login first before they are allowed to invoke doWork, how do I go about implementing such with multiple clients? since one client can login and another client can piggyback on the first client login to doWork, how can I prevent that?

[JosAH]

if my remote object has a login(), logout() and a doWork() method and I want each client to login first before they are allowed to invoke doWork, how do I go about implementing such with multiple clients? since one client can login and another client can piggyback on the first client login to doWork, how can I prevent that?

Your clients need to identify themselves, just as is done in those Servlets, otherwise your remote side can't tell the difference between clients. Given that client identification you can work yourself up from there. Think of RMI as Java's version of RPC.

kind regards,

Jos

[guest_user]

Your clients need to identify themselves, just as is done in those Servlets, otherwise your remote side can't tell the difference between clients. Given that client identification you can work yourself up from there. Think of RMI as Java's version of RPC.

kind regards,

Jos

hmm, any ideas how I can identify each client?

[JosAH]

hmm, any ideas how I can identify each client?

There are different scenarios:

1) the clients make up an id;
2) the server hands out an id after successful login.

the problem with 1) is that two ids might not be unique; the disadvantage with 2) is that the server needs to keep track of the ids already handed out.

kind regards,

Jos

[bigsonny]

Is this really a "New to Java" question? If it is, I need to do a lot of work!

[JosAH]

Is this really a "New to Java" question? If it is, I need to do a lot of work!

It's not really that difficult (read the RMI tutorial) but the op wants to have a notion of logged in clients and clients just 'passing by'; that complicates stuff a bit because RMI is almost the same as remote procedure calling, i.e. it doesn't offer any 'protection', it trusts anything that manages to connect to 'the other side of the wire'.

kind regards,

Jos

[guest_user]

There are different scenarios:

1) the clients make up an id;
2) the server hands out an id after successful login.

the problem with 1) is that two ids might not be unique; the disadvantage with 2) is that the server needs to keep track of the ids already handed out.

kind regards,

Jos

is it possible to use the thread id to keep track of each client? since I can't get the connecting machine's ip and port as rmi abstracts it out...

[JosAH]

is it possible to use the thread id to keep track of each client? since I can't get the connecting machine's ip and port as rmi abstracts it out...

You don't know if it's the same Thread (representing a client) that's consulting your RMI server, so no, a Thread id doesn't make it, you have to keep track of the ids handed out by your server (or made up by your clients).

kind regards,

Jos

[guest_user]

Let's say I hand out the IDs from the server end, what is to stop a client from spoofing their own ID?

[Singing Boyo]

Track what ID's you've given out, so clients can only spoof ID's that are in use. You also probably want to generate random strings as the IDs. Even with something like 12 characters, it's incredibly difficult to generate one that's in use. 62^12 is a really big number, and that's just with alphanumeric characters.