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

NX: To lock or not to lock, that is the question ....

 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the interface provided by Sun, the methods lock() and unlock() are public, suggesting that whatever application they use to admin the database will call lock and unlock itself before calling delete, modify and create. This causes the dilema that I feel its a bad idea to have the Data object FORCE locking by including lock() and unlock WITHIN the implementation of other methods.
For my own GUI it uses a different interface ( a lot simpler one) with no calls to lock or unlock. Locking is forced because the GUI will connect to an adaptor, not to the data object directly. This adaptor calls lock and unlock from with the reserveContractor() and releaseContractor() methods(book and unbook).
But this leaves me uber-nervous. I have no info on what the 'other' application will do. I cannot force it to thread safe behaviour if it decides to call delete without calling lock. But if I force lock within the delete call ill get double locking, which will deadlock.
How can you force thread safe behaviour if you have no knowledge of how the other application (which must exist) will behave
[ January 27, 2004: Message edited by: morgan bath ]
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Part 1
-----
I think an essential book, which will answer your particular question,
and many more, is Joshua Bloch's Effective Java: Programming Language
Guide.
In summary, if someone can mis-use your class or package, you need to
be specific about it in the JavaDoc.
Part 2
-----
A Java Interface does have, by definition, public methods. However, and I
haven't played with a toy example in a while, you might try this: what happens
when the implementing class is declared package private? I think you will
probably find that the methods are only package private and no longer
public.
Thanks,
Javini Javono
 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Unless my knowledge is a little out of dat I thought you could only override methods more public, id assumed the same was for interfaces. Besides it doesnt solve my problem:
The fact that lock and unlock are public methods included in the interface suggests the existing application uses a locking mechanism and does so on the record number, and independantly of the actual file altering methods. If I alter this do I not run the risk of alienating this system? I think so because the specs specify the interface and the name of the class to be used. This heavily smacks of "we have an exising Data.class which has these methods .... and we are just gonna point it at your new object when its finished and pray it works! Please dont make us cry."
 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How about this solution:
I have the DBMain interface that they sent, plus I implement DBServices interface of my own. On the later interface it demands two methods:
lock(int recNo, Object client) & lock(int recNo, Object client) where client is acuatly the object calling the lock / unlock method (note the adaptor class is always local so its pass by reference).
Now in the lock(recNo) method I simply run lock(recNo, this).
As far as I can see I now have total client control on my GUI and any other additions that go through my adapter class.
And for the old applications using the old DBMain interface they still have a simple locking mechanism with no way of knowing which client called the lock, and just hoping they are coded lock(), doSomething(), unlock().
I cant think of a better way without actually altering DBMain OR simply not implementing lock/unlock in DBMain. Either option sounds like an auto-fail to me.
[ January 27, 2004: Message edited by: morgan bath ]
 
Ken Krebs
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Morgan,
I wouldn't worry about the Sun testing app misbehaving. It has to live up to the contract specified in the DBMain interface. You just have to make sure your Data class does too.

Regarding your solution:
It's OK to have your Data class methods delegate to some other object, just as long as you meet the DBMain contract. The approach you describe looks good assuming of course that your Data class is not a singelton.
[ January 27, 2004: Message edited by: Ken Krebs ]
 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It isnt now BTW im not just worried about the sun testing application, im working on the assumption that being given a specific interface is not an artificial requirement, but indicates some existing application that is in use and still needed. eg. something that actually uses my delete() function
Its difficult to come up with logic behind a public lock(int recNo) I can tell you
[ January 27, 2004: Message edited by: morgan bath ]
 
Ken Krebs
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand your concern as my instructions say:
... because the data must continue to be manipulated for reports using another custom-written application ...

However, it would be true that this app must also obey the DBMain contract.
You MUST correctly implement all the functionality specified by DBMain, including the methods, including delete, that are not used by your client.
As far as the DBMain interface is concerned, it definitely sucks big time, but that too is a legitimate part of the test. :roll:
 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agreed. My specs are not as specific as yours on this, but I interpret them the same way. I am assuming Data.class will be used by another application, and that it WILL call all methods in DBMain including lock() & unlock(). Hell ive even provided a zero zero constructor even though I dont like it.
Im not even sure I can make the assumption that all applications will call one instance of Data for itself or whether they will share one between them, but im going to assume its one Data per app at this point because otherwise im never gonna get this over with.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic