Now the question is shall we pass the RemoteData object (which is the Client ID) as a parameter for a specific method or shall we create a method such as getClientID() in RemoteDataImpl class and call it from Data class (isn't that strange!)???
According to your comments, each client has it's own remote data object, and each remote data object has its own copy of Data. Or to put it another way, each client has its own copy of Data.
Couldnt you therefore use the instance of the Data class to indicate who has the lock? (Thread, hashcode, whatever you want to store in your HashMap).
Hopefully Max will add his comments to this.
You said: Suppose to put clientId and record number into hashmap
Yes, but client id is just anything that uniquely identifies the client.
I think you should not get too caught up in trying to code exactly to anyone's suggestions. Rather, you should look at what they are trying to achieve, and work out how that can be accomplished. This applies even if you can easily write code to accomplish the task - if you stop and think about it, you may find a better way of doing it.
What you are trying to achieve in this case is to get a unique identifier for the client that can be used inside the Data class.
You have the suggestion each RemoteData has it's own copy of a Data. So if we have four clients connected, each client has it's own RemoteData, each RemoteData has it's own Data, such that:
Now your question is "how do I get the instance "B" into the Data class so that I can identify that this is client number 2?"
My question is - why bother? It is not required to achieve the same results. You already know that the unique instance "b" of Data is used by client number 2. So you could use it to achieve exactly the same aims without having to change the method signatures or do callbacks.
I cannot see anything special about the RemoteData object which requires it to be the key.
If I am really missing the point of what Max was trying to achieve, perhaps you could post a link to the thread in question so I can see what he was writing.
Moving away from your question for a moment, though, where is this map being used? The signature hash.put(clientId, new Integer(recNum)) is not what I would expect for the Data class.
I would think that in the Data class, you would want to be able to look up whether a record is locked or not. This would imply that the record number would be the key, and the client ID (if the Data class is even aware of the client ID) would be the value to be stored.
But turn the logic around, so that the connection itself is concerned with which records it has locked, and then the signature you provided makes a bit more sense ... the connection itself might want to know which records a given client has locked, so it might want the client id to be the key.
This is the thread that I copied the sentence for Max Habibi,
Lock and Unlock Review
and this is another thread, actually very very long thread which is argument between Max Habibi, Eugene Kononov and Peter dann Haan
another Lock and Unlock Review
But I am interesting in something you said which is:
"My question is - why bother? It is not required to achieve the same results. You already know that the unique instance "b" of Data is used by client number 2"
Will you tell me please how I know that? isn't suppose to have the Client Id for that? or am I missing something here? thanks for your comments.
Max:each RemoteData has it's own copy of a Data
Andrew: You already know that the unique instance "b" of Data is used by client number 2"
Qusay: Will you tell me please how I know that?
If each instance of RemoteData has it's own instance of Data, then they map 1 to 1.
Going way over the top here, this bit of code should illustrate what I am talking about:
You should see as output, something like:
remote lock # A called by # 1
lock # a called by # A
remote lock # B called by # 2
lock # b called by # B
Far more lines will be shown, and the order is undetermined.
The important bit is that remote lock "A" is always called by client "1". It is never called by any other client, and client "1" never calls any other lock.
Likewise lock "a" is always called by remote lock "A". It is never called by any other remote lock, and remote lock "A" never calls any other lock.
Now I explicitly set some identifiers here, but I could just as easily have used Thread.currentThread() or Thread.currentThread().hashCode() to show as identifiers, however it may not have been so easy to read. You can try it if you like. Anywhere I use uniqueIdentifier in a System.out.println(), change it to Thread.currentThread().
Andrew: Now your question is "how do I get the instance "B" into the Data class so that I can identify that this is client number 2?"
My question is - why bother? It is not required to achieve the same results. You already know that the unique instance "b" of Data is used by client number 2. So you could use it to achieve exactly the same aims
Qusay: isn't suppose to have the Client Id for that?
The client id is just anything that can be used to uniquely identify the client. As Max put it:
Max: Finally, if your clever and you use a map, then you can store the ID of the locking Thread(or the Thread itself). This opens the door to addressing Eugene's (valid) concern about making sure that Client A can't unlock a record that client B locked.
To paraphrase: you can use the thread of the class doing the locking. The class doing the locking is an instance of the Data class itself, and it is operating on a static HashMap.
[ May 13, 2003: Message edited by: Andrew Monkhouse ]