Not lock/unlock again!

[Jo Fail]

I have been carefully reading many of the posts on lock/unlock and reckon that I have a fairly good understanding of the problem and possible solutions but not good enough it seems.
Let me try and succintly describe what I am doing and why it is not working!To keep it more simple I am just describing the non-local situation. I have also gone for the clientId being the actual connection object as it seems like the simplest concept.
I have just one instance of a server which creates a data object. The server also holds an instance of a HashMap within which I maintain details of records locks - key of record number with a client object associated with it. This client object is passed across to the server by the client in the lock/unlock signature.
I can potentially have many client side instances and have a factory creating RemoteConnectionObjects. These RemoteConnectionObjects send themselves (this) (or rather a reference to themselves) to the servers lock/unlocks methods along with the record number. In order to be able to do this I have had to make the RemoteConnectionObject serializable.
When I follow the code through my unlocks never work because the clientId is different for the lock and unlock within one booking. I write out to the console the object id that I send from the client and the object id that the server receives and although they are both RemoteConnectionObjects they have different ids. This I presume is because in order for the RemoteConnectionObject to be passed from the client to the server it is serialised and in effect becomes a new object on the server side - it might hold all the same data but is still a different object reference.
Can anyone shed any light on how I can keep my clientId consistent within one booking?

[Duane Riech]

This will probably start a firestorm, but I'll try to answer your question.
I'm only going to talk about the client/server issue since the local mode is straightforward.
If I understand your question:
FACT: You cannot use the the thread id to test who owns the lock. Forget it...This issue was talked about, debated, argued MANY times. You are NOT guaranteed that a client will use the same thread all of the time.
The only way I know of assuring that a valid client id is used when locking/unlocking a record, is to create a unique client tag for each instance of the client then overload the lock() and unlock() methods to pass a second argument of the client tag and use that when locking/unlocking the records.
I know, I know... You're suppose to use the method signatures as defined by the requirements. My guess is that's part of the gray/unknown part that you have to justify in your design consideration submission.
All I know is that this has been discussing over and over and that you CAN'T use thread id /name as a tag.
This will probably start another argument, so I'm staying out of it from this point on.
Hope this helps....

[xin dong]

sounds bad.
I don't know your solution's feasibility.but I think it's no need to send any obejct like RemoteConnectionObject from client to server.

[Max Habibi]

Hi Jo,
If I understand your question correctly, you're not using the thread ID in any way: is that correct? I didn't see any references to it in your post.
Basically, if you interpret the requirements literally(lock must be implemented in Data, do not change method signatures), then I see two options.
1. Use a static map inside of Data, and keep your locks in that. Thus, a given Data object locks using myMap.lock(this,recno). Because this structure is static, it is shared across all instances of Data, thus all clients will be aware of each other. Of course, each client will have to get their own Data object, either directly or indirectly.
2. Similar to the above, but instead of using a static hashmap, have the remote server create a hashmap for all Data objects that refer to a given db.db file, and explicitly pass this reference to each Data. This achieves the same result as 1), but doesn't tie you down to a single database. This is similar to the approach you're describing above, but allow the requirements to be more strictly interpreted, because the Data class will actually be doing the locking, and you won't be changing the signature of the Data class. You will, of course, have to provide a Data.setMap(Map map) method on Data, for the use of the server.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Jo Fail]

Hi all
Thanks all for your input.
I wasn�t trying to use the thread id as I gather from previous posts that it may be unreliable.
Basically the way I currently have my lock design (yes I�ve changed it a few times!) I have one server which holds one copy of Data and also one HashMap for tracking locks. I have many clients and was (I see now rather foolishly) trying to uniquely identify my client by passing an object reference from the client to the server. Clearly there are better ways of identifying my client � maybe generating an id from the date and time or using some random number generator from the API - what would be the best way I�m not sure � any suggestions would be welcome. I think that my current design will work if I sort out a good way to generate a unique client id � it may not be the best way but it is A way and from all my reading and from the fact that there are sooooo many posts on this subject there isn�t really way to solve it ideally.
Max I really am having a hard time getting my head around your idea of having multiple Data objects. As far as I can see it I will only have one server and the server is there to control the Data access, so I can�t see how the concept of having multiple Datas can work � please could you explain it in more detail?
Regards
Jo

[Max Habibi]

Think of it this way. You have a Factory, which is a RemoteObject. The role of this factory is to provide RemoteData objects to GUI clients. Of course, the RemoteData objects are also Remote Objects. However, these remote Data objects share a static map. This static map tracks the locks. In principle, this isn't unlike the Home in EJBs.
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ April 09, 2003: Message edited by: Max Habibi ]

[Kevin Cao]

This is good post that you can reference.
Kevin

[Sam O'Neill]

I like this solution but do forsee one problem with having each client with its own copy of Data which I can't find a way around with relation to the recordCount.
At the moment the add method is not used however it still needs an implementation and the current code would increment my recordCount then try and update the value in the file.
Now the problem is that if we have 400 clients all trying to update the recordCount field in the file because they are all adding records and the synchronization has effectively been bypassed due to the multiple Data instances how do I ensure that they each update this field and add thier new records in turn? Plus my local copy of recordCount will constantly be out of tune with the actual figure as it currently only accounts for count changes made by this Data instance.


Many thanks Sam

[Max Habibi]

True,
The record count issue has bothered me for some time. One solultion is to make recordCount static, and protect it against concurrent access. Another is to read the record count from the file each time it is used.
M

[Raffe Paffe]

At the moment the add method is not used however it still needs an implementation and the current code would increment my recordCount then try and update the value in the file.

Do i understand you correct that i cant leave the add method as it is? Do i have to change it?

[Andrew Monkhouse]

Hi Raffe,

Do i understand you correct that i cant leave the add method as it is? Do i have to change it?

My personal view is that we do not have to modify the add method, nor do we need to provide a live update when it is used.
My instructions state "Three classes ... Data, DataInfo, and FieldInfo. With the exception of ... [criteraFind, lock, & unlock] ... these classes are complete and functional".
(editing is mine)
Therefore we do not need to modify the add method.
Further on it states: "It is not necessary to provide for live updates on multiple clients when new bookings are made on other clients".
Extending this, I believe that we do not need to provide live updates if the recordCount changes.
I am not providing the user with any indication of how many records are in the database. I only care about how many match their criteria. This changes whenever the criteria changes. So if some (imaginary) application adds a record to the database, then the next time the criteria changes, if the new record matches the criteria, I will get it. If it doesnt match, then I dont care about it.
Interestingly, I suspect that if a record is deleted (again by this imaginary other application), I think I can still book flights on it - I think that fixing this may be out of scope as well.
Regards, Andrew

[Sam O'Neill]

I wasn't so much concerned about another application calling add() or modify() as the FBN application itself needing the requirment at sometime in the future. To me it seems counter-intuitive to have a class with some methods that would not work if called under current conditions.
I think I'm going to have to give this some more thought....
Thanks for your responses guys
Sam

[Sam O'Neill]

Just another thought Max - have you then changed all the signatures of the Data class methods to no longer be synchronized as I assume you are synchronizing on the static Map instead so a synchronized method that then synchronizes on another object seems like a bit of a no, no to me even if in this implementation we are sure no other clients will be using the same instance.
I feel as if this solution is leading to make too many changes to the Data class when the spec does say that the bar the unimplemented methods the code is 'complete and functional'.
I just don't see how a nice solution is possible having just one Data instance either though if I implement the lock(recNum) and unlock(recNum) in the Data class. Has anyone manged to get this to work without overloading or changing the methods to take an id of some sort?
My head is beginning to hurt with all this thinking!
Thanks Sam

[Max Habibi]

Originally posted by Sam O'Neill:
[QB]Just another thought Max - have you then changed all the signatures of the Data class methods

Not @ all Sam: Not signature changes of any type are neccessary.
M

[Max Habibi]

Originally posted by Sam O'Neill:
I wasn't so much concerned about another application calling add() or modify() as the FBN application itself needing the requirment at sometime in the future. To me it seems counter-intuitive to have a class with some methods that would not work if called under current conditions.
I think I'm going to have to give this some more thought....
Thanks for your responses guys
Sam

Well, actually, in the exam that you have, I don't think that the delete method technically works, because it doesn't does decrement the record count. Thus, the Data class doesn't seem to work as is. If it needed to, IMO the delete method would have to change.
M