RMI/threads/locking

[vin miller]

This project is my first experience with RMI.
From various posts I have inferred that RMI creates a thread for each client request. This makes plenty of sense, but there is no mention of it in the java tutorial, which is what I have been using as my learning resource for RMI.
So if the Data class is part of my RMI server(db server), and the RMI server provides clients with access to the Data functionality, each client request to the RMI server for access to Data will be an individual thread created behind the scene by RMI? How can I refer to this thread to call wait() on it? Will this.wait() work?

[Vladan Radovanovic]

Originally posted by vin miller:
This project is my first experience with RMI.
From various posts I have inferred that RMI creates a thread for each client request. This makes plenty of sense, but there is no mention of it in the java tutorial, which is what I have been using as my learning resource for RMI.

Hi, just to let You know that RMI engine makes no guarantee that it will make a new thread for each client, meaning it might or it might not.
This has been posted here alread but here it is again http://java.sun.com/products/jdk/1.2/docs/guide/rmi/spec/rmi-arch.doc2.html

[Adrian Yan]

That's why it's good to create a singleton pattern for server creation.

[vin miller]

If I start a thread from the RMI server to assign a lock for a requesting client, then how will the client know to wait until the lock is assigned? The call to the RMI server will return to the client after the thread is started, possibly without a lock being assigned. When the client then calls modify, how is it to know the lock was assigned? I could keep checking from the client, but won't that drag down the server?
Also, when calling the RMI server to execute modify, how is modify to know the client that is executing it without changing it's signature like many did with lock. I don't want the changes to data to get too out of hand.

[Dave Boden]

Adrian,
Could you please expand on what you mean by a Singleton pattern?
This aspect of the project is causing all my remaining problems!


My Database requires that each client is represented by a separate thread. The thread reference is kept with a lock to ensure that only the client that locked the thread is allowed to unlock it.


The problem of ensuring that each client is represented by a separate thread on the server side seems to be a very difficult one.


Cheers,
Dave

[Adrian Yan]

Singleton is a design pattern that if implemented right, there exist only object (single), namely your data server.
I don't see the point of tracking client id, you only need this if you implement the booking schema on the client side, however, in the FBN assignment, booking function should be implemented on the server side. This means, in your booking method, your code will call the lock and unlock, since this method is probably has synchronization schema, only one client can enter the method to lock, read, modify, write, unlock in a sequence.
I hope this helps.

[Dave Boden]

Thanks, just to clarify the point of locking. We're already guaranteed that each operation on the Data object is atomic (due to the methods being <code>synchronized</code>. Obtaining a lock means a client can read a record, process for a few seconds, and then write a new result back without fear that the data has changed, potentially causing race conditions.
You seem to be suggesting that we add methods to make the operations of booking a seat atomic. i.e. The client does not call getRecord() and modify(), it calls a new method bookSeat() which does all this for it invisibly. However, I'm worried by this part of the instructions given to us in the project download:
<h3>Writing Data Client</h3>
To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration.
I'm not sure whether creating such atomic operations is a valid solution to the project?
Any thoughts? Thanks, Dave
[This message has been edited by Dave Boden (edited February 15, 2001).]

[Adrian Yan]

Dave:
If you want to put the booking in client side, that's fine too. No matter where you put the booking schema. A booking method is always there, it's this method that should guarantee the atomic operation, using synchronization technique. However, it's simple for me to put the booking in server side.
As far as the client implementing the public methods, there is a good post (I don't remember who) on this subject.

[Dave Boden]

Adrian, I think that you may be more trusting than me
Are you trusting the client to not unlock a record that another has unlocked?
I imagine a fearsome gunbattle between the client with the white hat (written by me) and the client with the black hat (out to kill me, or at least damage my reputation as a programmer )
The white hatted client locks record 1 and processes. In the meantime, the rogue client unlocks record 1 (what's stopping him??). The white hatted client's friend then comes along and locks record 1... All sorts of race conditions ensue between the two white hatted clients!
Can you explain how your approach will defend against this? I think that we can assume that the hashcode of a client is enough to prove that the client is who he says he is. (i.e. authenticating each client using public / private keys is a bit over-the-top!)
My point is that the client must not be relied upon to behave. If I have missed your point, please put me straight.
Please excuse my tired cowboy puns!
Best Regards,
Dave

[Adrian Yan]

I agree with you on the trustiong of clients. However, this issue is not addressed in the requirement. It's very clear in my requirement that, The client will perform lock, read, modify, write, unlock SEQUENCE. That's where booking method comes in.
Should you track the client? Sure, but the point is that, since the requirement mentions nothing about it, then why do you bother with it then?
As far as the rogue client concern, that's a step down the road. If you use hashcode, who's to say, that someone not gonna write a rogue client that can imitate it.
My point is that, if requirement says nothing about the tracking of clients, then, I won't bother with it.

[Dave Boden]

Adrian, you're absolutely right about the requirements, I've just been over them again.
However, if two clients attempt to perform the sequence lock, read, modify, write, unlock concurrently, then both modification attempts will be handled correctly.
We can assume that the client behaves! I was overcomplicating things. However, I'm glad I've thought about it all. Maybe it will stand me in good stead when I get to the exam?
Hats off to you! (both white and black )
All the best and many thanks for making my life a lot easier,
Dave

[Adrian Yan]

I can die a happy man now!