cancel
Showing results for 
Search instead for 
Did you mean: 

Java RMI question

Former Member
0 Kudos

Hey guys...

I have got a theoretical question about RMi and Java...

Do I have to implement any synchronizations on the server side?

I'm not sure but... RMI does the whole socket communication stuff... so if a client gets a Stub-Instance of my ServerImplementation object the client is possible to call functions on the server side. (Client --> RMI Stub --> RMI Skeleton --> Server)

If there is only one client... I do not see any problems.

But what if there would be more than one client. Maybe 10. And every client tries to execute the same server function at the same time.

And the server function does some operations which needed to be synchronous. (withdraw or deposit some cash for example).

In my opinion it is only possible to execute one server function at different times. Never at the same time. Of course there could be many connections at the same time, but there is only one existing server implementation instance running. So if one Sekeleton calls the Server function it should be automatically lock the server implementation object and the other clients are not allowed to execute server functions.

Am I right with this thing?

May you help me clarifying this theoretical question.

Thanks and regards

Markus

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hello Markus,

Section 3.2 of Sun's RMI specification (http://java.sun.com/javase/6/docs/platform/rmi/spec/rmiTOC.html) says

A method dispatched by the RMI runtime to a remote object implementation may or may not execute in a separate thread.

That means that you cannot assume a single-thread behaviour on the server (even though as far as I know Sun's own RMI implementation uses a thread dispatching mechanism which executes incoming RMI requests sequentially).

Hope this helps; best regards,

Jens

Former Member
0 Kudos

Hey Jens....

thank you for your help. This do not solve my implementation problem but now I'm able to consider the fact.

Best regards,

Markus