whether the server should accept client requests with different database name

[goeshome, rnd]

I have couple questions, will some one please help me out!!
1. I am getting confused whether I should let the server accept the client requests with different database name. For example, one client ask for "db.db", another ask for "db1.db" and manage all these instances.
It is not useful for this specific application, but whether I should do this or not.
2. If I have one server running, while some client is connecting to it, one local client also connect to it using local mode. How the lock protection works?
3. If the client try to close the db, but actually, there are still some one else connect to it, use count to solve this? If the client forgot to close it, what will be the solution.
4. For the lock, if the client lost the connection before unlock, how to ensure it will be unlocked. I see some one mention that the rmi can not ensure the sequence client request will be responded in the same thread at server side. So, it won't be possible to use thread tracking to solve this problem?

[Peter den Haan]

Originally posted by goeshome, rnd:
1. I am getting confused whether I should let the server accept the client requests with different database name. For example, one client ask for "db.db", another ask for "db1.db" and manage all these instances.

There is no need to do this. I personally did, because it fit so well with my object model more than anything else, but I don't think I got any points for it.

2. If I have one server running, while some client is connecting to it, one local client also connect to it using local mode. How the lock protection works?

It doesn't. If the database is accessed through the network, it should not be accessed in local mode.

3. If the client try to close the db, but actually, there are still some one else connect to it, use count to solve this? If the client forgot to close it, what will be the solution.

close() should not close the actual database in networked mode. It should close the connection. You could close the database when the last client closes, but what's the point?

4. For the lock, if the client lost the connection before unlock, how to ensure it will be unlocked. I see some one mention that the rmi can not ensure the sequence client request will be responded in the same thread at server side. So, it won't be possible to use thread tracking to solve this problem?

Indeed, it won't, fortunately the solution is even simpler. Check out java.rmi.server.Unreferenced.
- Peter

[goeshome, rnd]

thanks Peter, it helps a lot!!