No, you're absolutely spot-on.Originally posted by Arvind Prabhu:
On one hand, the requirements are pretty clear in stating the exact signatures of the "lock" and "unlock" methods. The signatures as given neither accept any sort of client identification nor do they return anything. However, on the other hand, the requirements also clearly state that no action is to be taken if a client tries to unlock a record which the client has not locked (Please correct me if I'm wrong).
But are they?Since these two seem contradictory [...]
Why? In a local database, there's no need for locking at all. I'd say that the "implementations" in the Data class are fine as-is. There's certainly no need to synchronize themIn addition, the signatures for lock() and unlock() seem incomplete anyway, since both of them should be "synchronized" because wait() and notifyAll() are called within.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Can you explain to me exactly why you would need a HashMap in Data?Originally posted by Arvind Prabhu:
1. The lock and unlock methods of the DBServer class could take in a client ID and perform client ID specific checks and call the lock and unlock (without a client ID) in the Data class. But the drawback here is that the locking mechanism would have to be placed in both the classes - NOT good. Basically I would need a HashMap in both the DBServer and Data classes.
This approach does not sit easily with the requirements, which appear to ask you to create a network-enabled version of Data that could be reused in other projects. Putting client-specific code in the server appears to step outside both requirements to some extent. Having said that, judging from what I've seen, if you argue why this is the best way to do this you'd pass.2. Another issue deals with the method that actually books a specified number of seats on a specified flight. I could place this method in either the client or the server. The method basically finds the record, locks it, tries to modify it, and unlocks it. Instead of making these individual calls from the client to the server, I thought I would put this sequence of calls within a single method in the server. Too much network overhead if this method is placed in the client. Any thoughts?
Ah, now that depends entirely on what the methods in the server actually do! So that's a question only you yourself can answer, for each method individually, while you are coding them.In addition, since most of the methods in the Data class are synchronized, would any of the methods in the server class need to be synchronized? I don't see the need. Note that the server class just acts as a proxy to the Data class.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Originally posted by Peter den Haan:
Can you explain to me exactly why you would need a HashMap in Data?
This approach does not sit easily with the requirements, which appear to ask you to create a network-enabled version of Data that could be reused in other projects. Putting client-specific code in the server appears to step outside both requirements to some extent. Having said that, judging from what I've seen, if you argue why this is the best way to do this you'd pass.
Ah, now that depends entirely on what the methods in the server actually do! So that's a question only you yourself can answer, for each method individually, while you are coding them.
Originally posted by Matthew Comer:
You dont have to modify the lock() and unlock() method signatures to satisfy both requirements...
Design a "Connection" object that implements Remote. This object also implements your data interface. Now, you have a proxy object that serves two purposes - a) it allows remote connectivity to your data object, and b) it allows you to do some clever things BEFORE and AFTER you pass the request on to your data class. Specifically, now you can register that a given thread is working on behalf of a given connection in some sort of "thread connection registry" that you will implement. So, in your connection class:
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Originally posted by Arvind Prabhu:
...I've also read that RMI does not guarantee that the same thread will be used from one method invocation to the next.
-Arvind
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Originally posted by Jon Trussler:
Matthew, Peter, etc,
public void lock(int recnum) throws...
{
try
{
ThreadConnectionRegistry.registerThreadConnection(this);
data.lock(recnum);
}
finally
{
ThreadConnectionRegistry.unregisterThreadConnection();
}
}
Wouldn't "this" be the "Connection" object that you refer to, which is RemoteDatabase in my case? And in that case, isn't the connection object the same for all clients connecting remotely? Obviously it cannot be since you identify the client holding the locks by connection object.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Originally posted by Matthew Comer:
I'm still not sure you guys are seeing what I was talking about.
My purpose for registering the Thread->Connection relationship is only so that I don't have to pass a connection id around. Any code that needs to know what the current connection is (i.e. which connection the current thread is working on behalf of) can just call ThreadConnectionRegistry.getCurrentConnection().
Matt
Don't. You don't need it. The Connection object itself is a perfectly valid UID.Originally posted by Andras Nemeth:
I have an instance variable, called ClientID, in the Connection class. It is an UID or ObjID and it got a value every time when the ConnectionFactory create an instance of the Connection.
I have a (Let's say one.) GUIClient and an FBNServices object, which of these should have an connect method to return the Connection object... (I assume the second one.)
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Originally posted by Peter den Haan:
Remember, what identifies the client is the Connection object he's talking to; not the Thread he happens to be executing in.
Regarding your earlier response: you don't need any locking code in Data. It is worth thinking of your objects in terms of responsibilities and collaborations here. Data's responsibility is looking after a local database. Locks aren't part of that.
-Peter Crowley,<BR>who is looking for work in North Florida
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
PI day is 3.14 (march 14th) and is also einstein's birthday. And this is merely a tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
|