This is a good discussion on using Unreferenced. Pay close attention to Peter's posts on the subject, he's the real guru here.
Originally posted by Sarita Gupta:
Will appreciate if u cld refer me to Peter's postings... i mean in case u'r refering to a particular posting of his.
Now I am working on the GUI and I have this question:-
1. How should I determine what record number to lock or unlock? Should I create a method in the data class to get the record number?
Add a method inside DataAccessFacade and pass it the flight number from the GUI. This method will call the find method in Data which returns the DataInfo object. Now it will call the getRecordNumber on the returned DataInfo object and will return the recordNumber that can be passed to the lock method.
One more thing that I would like to ask is while performing the entire database lock with lock(-1), should I also store the clientID who is asking for the database lock. And then while asking for the database unlock unlock(-1) should I also chek the clientID and if its the same clintID who did database lock, it will unlock the database.
... I read your post and feel that you are bypassing these functions as well, is that true? Does it matter if we bypass the functions defined in the Data.java at all?
By the way, how do you justify the decision about bypassing the functions in Data.java in the design document?
Originally posted by Samual Harvey:
Yes I did the same. Data.java has two empty methods lock and unlock. These methods I also added inside my DataInterface. So it is implemented by both the remote and local classes, although in local mode I do not use the lock and unlock.
Originally posted by Pete Lyons:
... The only thing I'm wondering is if you are to expect that more than 1 local client might access the same database (maybe with remote X11 or whatever), and in such a case, you would want locking just like when you are serving multiple clients via the network.
Originally posted by Thomas Fly:
Why do you need a LockManager at all? ...
So, why not simply add a synchronized readModifyTransaction() method to the Data class, which would first call the existing read method, then the modify method?
Thanks Michael, I expected something like that, but as one still not entirely out of the C swamp, I just wanted to hear somebody say it.
For you or anybody else then, where does lockManager "hook-in," so as to prevent other threads from accessing locked records?
It appears to me that Data.seek(recno) should be modified, so as to check whether or not a locked record is being accessed, and then wait() if the client isn't the lock owner.
Presumably, lockManager will have a checkLock() method for this purpose.
... it's permissible to read a record that may be include in a transaction that will ultimately modify the record; the primary point of record locking is to ensure database integrity (e.g., 2 different clients purchasing tickets "simultaneously" will result in 2 fewer seats on the plane).
Hmm... well how did you implement criteriaFind?
... but since the application has been written by a Sun Certified Java Developer (flourish of trumpets), B will presumably do a lock before it does an unlock (i.e., lock-read-modify-unlock), just like A and every other client. It seems then that B would be blocked- waiting to acquire the lock- from unlocking the record that already has been locked by A.
It seems to me that a more troubling issue is the possibility of client A having network or power problems before having the chance to unlock the record that it's just locked.
I don't believe addressing that issue is in the requirements, so can one just mention the problem, without taking the trouble to code it?