Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

lock signature vs. requirements

 
Geir Morten Hagen
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've just successfully implemented record locking, but have a slight problem with making the methods adhere to the requirements. The requirements state:
The remote client code that you write must provide all the public methods of the suncertify.db.Data class
Fair enough. I'm using a class called DataFacade which is the remote object implementation of the remote interface. What this class does is to just pass on the method calls to Data, except for the lock and unlock methods. In the interface they have these signatures:
public void lock(int record)
public void unlock(int record)
The implementation of these calls the Data methods:
public void lock(int record, String clientID)
public void unlock(int record, String clientID)
based on the hostname of the client to identify the ownership of the lock.
The problem is that the signatures for lock and unlock in the interface and in Data differ, because Data isn't implementing the interface, the facade is.
Do you think I will get any penalty because of this? Any workaround?
[ April 09, 2002: Message edited by: Geir Morten Hagen ]
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Geir,
Boy, I'm beginning to think we need to change the name of this forum to Lock-Unlock
I was doing something similar (almost identical as a matter of fact) but I kept seeing Mark's posts on unique remote objects and finally came to the conclusion that there is no need to change the lock-unlock signatures.
Having said that, I know that many have done what you are doing and passed the exam. So if you're comfortable with it (which you may not be since you're posting this) then do it and document your reasoning.
Michael Morris
[ April 09, 2002: Message edited by: Michael Morris ]
 
Bhuvan mehra
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi Geir,
in my assign. only one thing is left that's lock/unlock.
my design is similar. i also thought to provide lock(rn,id) to client. but after reading you message i go through instructions again. and it says
--------------------------------------------------------
Record locking must be implemented using the methods public void lock(int) and public void unlock(int).
---------------------------------------------------------
this was the first line.
what i have noticed through the forum is that if you change the sign. and justify it. and if your assign. works prefectly, you can pass easly.
but what i feel is, changing sign. means loosing some points.
if you get some better sol. to the problem, please share that.
a suggestion, as an id you are using string. you can use java.rmi.dgc.VMID. VMID will be always unique for every client. vmid is (localhost+objectaddress+?+hexavalue).
-------------------------------------------------------------
The remote client code that you write must provide all the public methods of the suncertify.db.Data class
-------------------------------------------------------------
to fulfill this instruction we can change sign. of lock(rn, id) in Data class.
need your comments.

regards,
bhuvan.
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Geir and Bhuvan,
As we say down here in Texas, "I ain't one to beat a dead horse", but you guys need to do a search on this forum for Connection Factory or Connection Object. Especially look for Mark Spritzler's posts on the subject. If you're concerned about changing the lock-unlock signatures DON'T, just use a unique connection object for each client and don't allow that object to unlock records it has not previously locked.
Hope this helps
Michael Morris
 
Greg Georges
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Geir,
Well, not too long ago I had this question, and was wondering if changing the signature was a bad idea. Well, I did change the signature (however the lock and unlock methods were in my adapter classes) and I gto 149/155, so I do not think I was penalized for it. Look, in my explanations of the design document I mentionned that in my 2 years experience of Java programmimg, it often occured that I had to change the method signature of an analyst's class diagram and that this was a normal practice. I think if you document your choice, you should have no problem. However, I take no responsibility for your choice, I did it and thats that
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Try this design with no change in lock signature methods:
Every Java object has a hash code which you can retrieve using hashCode() method in the Object class. Every remote implementation instance of Data interface will have the unique hash code since they are instantiated in the same VM. All you have to do is check this hashcode in the LockManager to match the client with the lock record. No need to change the Lock/Unlock signatures or add a seperate client id.
I've tested this theory and I am sticking to it!
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Every Java object has a hash code which you can retrieve using hashCode() method in the Object class

Yes that is true, but will a junior level programmer understand this or know this is true. The other question to ask is why is this so. What purpose was this hashCode method in the Object class created. For the equals() method, which determines if an Object is equal/the same object to another. Which is what we want. However, I say that if you use the Remote Object methodology, where each client has their own Remote Object, then you don't ever have to check equality, or clientID, or anything, you can just have it lock the record. It is less code, easier to read, and very easy to implement, and no Theories to test.
Mark
 
Geir Morten Hagen
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for all help and suggestions, guys!
 
Geir Morten Hagen
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've decided to change the signature in Data and use the DataFacade to call the methods.
Now I was thinking of having a reference to a LockManager interface in Data, instead of a reference to the actual implementation. At runtime the application spesific extension of Data (in this case BookingData with the bookSeats() method) instantiate an implementation of the LockManager interface and sets the LockManager reference in Data to this instance. If no instances are set, Data can assume that record locking is not being used.
I see this as a perfect way of letting Data abstract away from the actual record locking implementation, just relying on the methods supplied in the LockManager interface. Or is this overuse of interfaces and makes the application more complex than necessary?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic