Definition of a record locked for modification

[Rob Doran]

I interpret Sun's locking spec to say that a record can be modified only if it has been both locked and read, in that sequence. I don't see how all of that can be accomplished with a single HashMap (unless one encapsulates multiple attributes in a "lock" class) as has been suggested repeatedly in this forum. My question is "Am I correct in thinking there's more involved, or am I making this thing more difficult than it has to be?"

[Michael Morris]

Hi Rob,

... My question is "Am I correct in thinking there's more involved, or am I making this thing more difficult than it has to be?"

Definitely the latter. All you need to do is map the client to the lock. Remember it is "write" lock only. All other clients are free to read the locked record at will. When a client owns the lock he can then read and decide whether or not to modify and finally unlock. Really pretty simple.
Hope this helps,
Michael Morris

[Rob Doran]

Originally posted by Michael Morris:
Hi Rob,

Definitely the latter. All you need to do is map the client to the lock. Remember it is "write" lock only. All other clients are free to read the locked record at will. When a client owns the lock he can then read and decide whether or not to modify and finally unlock. Really pretty simple.
Hope this helps,
Michael Morris

[Rob Doran]

Thank you Michael,
I agree that any client should be able to read without first locking. But for a client who is updating, the only valid sequence is lock-read-update-unlock. If instead, client-a does read-lock-update-unlock, the record read may have been modified by client-b between the read and the lock done by client-a. The result could be a classic case of data corruption.
Rob

[Michael Morris]

Hi Rob,
That's why you don't do it that way. So really the sequence is read-lock-read-modify-unlock. The first read may be stale by the time you lock, hence the second read.
Michael Morris

[Rob Doran]

So it seems that you and I are differing on where some responsibility belongs. You seem to be saying that the client is solely reponsible for not doing an invalid sequence that can have a bad result on the server. I'm saying that perhaps the LockManager, being a server component, should bear some of that responsibility has well. I'm not sure it's sufficient in a distributed application to just say "the client shouldn't do that".

[Michael Morris]

What I'm saying is fail-safe locking schemes are well beyond the scope of the assignment. To quote the RHE: "Locking does not have to be bullet-proof from the unknown." There is nothing to prevent you from creating a robust fail-safe locking mechanism for this assignment, but it won't gain you a single point and may cost you on general considerations if it is very complex and difficult to understand by a "junior" programmer as the instructions indicate.

Michael Morris

[Rob Doran]

Michael,
I understand your point now. And judging from all the locking discussions I've followed in this forum, I'm nearly ready to believe that I'm the only one who believed that a more elaborate scheme was necessary.
Speaking of interpretation, I'd appreciate if you (or anyone else) would offer your comments on where the LockManager methods are invoked from. I have a RemoteData class that implements DataInterface. It represents a remote connection -- each client gets a different instance of it from the ConnectionFactory. Sun's Data class also implements DataInterface, and all connections forward method calls to a single instance of it. You and others have said in this forum that calls to LockManager belong in RemoteData.
Sun's instructions say "Part of your assignment will be to enhance the Data class ... You are required to implement the criteriaFind(String), lock(int) and unlock(int) methods...". I initially took that to mean that those methods must be implemented either in Data or a subclass of Data. Am I once again reading something too closely? Or have I misunderstood something I've culled from this forum?
Thanks for your help,
Rob

[Nate Johnson]

Originally posted by Rob Doran:
Michael,
I understand your point now. And judging from all the locking discussions I've followed in this forum, I'm nearly ready to believe that I'm the only one who believed that a more elaborate scheme was necessary.
Speaking of interpretation, I'd appreciate if you (or anyone else) would offer your comments on where the LockManager methods are invoked from. I have a RemoteData class that implements DataInterface. It represents a remote connection -- each client gets a different instance of it from the ConnectionFactory. Sun's Data class also implements DataInterface, and all connections forward method calls to a single instance of it. You and others have said in this forum that calls to LockManager belong in RemoteData.

RemoteData is where I put the call to LockManager.

Originally posted by Rob Doran:
Sun's instructions say "Part of your assignment will be to enhance the Data class ... You are required to implement the criteriaFind(String), lock(int) and unlock(int) methods...". I initially took that to mean that those methods must be implemented either in Data or a subclass of Data. Am I once again reading something too closely? Or have I misunderstood something I've culled from this forum?
Thanks for your help,
Rob

It depends if you are going for that extending data or that modifying data aproach which you will be talking about in your design choices. It looks like you went for the extends approach with your RemoteData, probably a LocalData as well.
Anyway, people have passed doing it either way, and as long as you can back it up in your design choices doc, you shouldnt need to worry.

[Michael Morris]

Actually there is a third less obvious way (and some might argue in contradiction to the instructions) and that is neither modify nor extend Data and create dynamic composites instead. I have always felt that a "has a" relationship is far superior to an "is a" relationship. When I decided to go with this approach, I was concerned that I might lose significant points, but I guess I convinced the assessor that my way was a viable alternative.
Michael Morris

[Rob Doran]

Originally posted by Nate Johnson:
[QB]
It depends if you are going for that extending data or that modifying data aproach which you will be talking about in your design choices. It looks like you went for the extends approach with your RemoteData, probably a LocalData as well.
QB]

Hi Nate,
No, actually I modified the Data class directly. My RemoteData is not a subclass of Data. All the two classes have in common is that they both implement DataInterface.
I have several instances of RemoteData (one per client), but only a single instance of Data. Are you saying that I don't really need both classes?
Rob

[Nate Johnson]

Originally posted by Rob Doran:

I have several instances of RemoteData (one per client), but only a single instance of Data. Are you saying that I don't really need both classes?

No... that sounds good to me. I didnt make my Data class implement the DataInterface (just because I didnt want to change it if I didnt have too), but one instance of Data that each of your RemoteData instances talk too is just how I did it.
Now, each of your RemoteData instances have a reference to the one Data right? That is how I did it anyway. Then the RemoteData just talks to Data to do what it needs, including some mechanism for locking when needed (I used the LockManager class talked about all over this forum).

[Rob Doran]

Nate,
So now that we agree on basic architecture, back to my original point...
It seems to me that the LockManager methods must be invoked from RemoteData objects. It would make no sense to invoke them from that single instance of Data, because there would be no simple way of uniquely identifying each client as a lock owner. Yet, Sun's instructions seem to say that lock(int) and unlock(int) must be implemented in the Data class or in a subclass thereof. Am I missing something or simply reading too much into Sun's instructions?
Thanks,
Rob

[Rob Doran]

Originally posted by Michael Morris:
Actually there is a third less obvious way (and some might argue in contradiction to the instructions) and that is neither modify nor extend Data and create dynamic composites instead. I have always felt that a "has a" relationship is far superior to an "is a" relationship. When I decided to go with this approach, I was concerned that I might lose significant points, but I guess I convinced the assessor that my way was a viable alternative.
Michael Morris

Michael,
Can you elaborate a bit about dynamic composites? I (and possibly several others here) am not familiar with them. Do they have to do with the Composite design pattern?
Thanks,
Rob

[Nate Johnson]

I did exactly what you are saying... I put them in my RemoteData class. That way, the RemoteData can be passed along to the LockManager as the unique id for locking the record.
I left the lock and unlock methods empty in my Data class.

[Michael Morris]

Hi Rob,
I used a Builder Pattern (which is a creational pattern like Factory), which defers the creation of the composite until runtime. You can have any number of composites in the scheme. In my case there were three. You have a Director class that directs the building of the composites which holds a reference to a Builder. Inheritance (the Builder class being the root) is used to create your different composites. There are public build methods like buildData(), buildLockManager(), buildSearch(), etc. to create the various components of the final composite. In the root class, all of these methods just return null and are overloaded in each of the children as appropriate to return a real reference to the particular component. Finally there is a method named getData (or getProduct or something similar) that returns the type of composite created. So to create a local DataAccess implementation you would do something like:

    ConnectionDirector director = new ConnectionDirector();
    DataAccess data = director.createConnection(ConnectionDirector.LOCAL, dbname);

The ConnectionDirector declares a reference of the root Builder, then instatiates the appropriate child Builder, calls all the build methods and then returns builder.getData().
Hope this helps,
Michael Morris
[ August 25, 2002: Message edited by: Michael Morris ]