Richard Brooks

Greenhorn
+ Follow
since Mar 10, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Richard Brooks

My advice is to check the validity before locking, so you will never lock a invalid record.



Couldn't thread-b mark a record deleted while thread-a was wait()ing for the lock so that while the record might have beenvalid before thread-a tried to get the lock but invalid after thread-a actually got the lock?

Richard
Alan,

Yes, right. That's exactly what I was talking about. Well summarized. Thanks for the clear answer/explanation of what you've done.

Just playing devil's advocate here, understand...umkay?...cause I think thats' what'd be most helpful to both of us..okay?

<devils-advocacy>
Your implementation of how LockManager deals with the concept of record validity minimizes the leakage in terms of lines of code and simplicity of the interface between the Data class and the LockManager, yes. But...it's still there in an OO design sense. So your LockManager implementation is forever bound (by a single teeny-weeny method call, granted) to the Data class/DBAccess interface.

Just off the top of my head, though, I wonder if by letting the LockManager not care about validity of the record but letting your Data class be the only one to know/care about could be made to work? After all, the Data class is very familiar with record validity and knows how to compute it...I wonder if we could help him keep that nasty secret to himself.

That way LockManager, lucky simple-minded young scoundrel he is, could dispense locking/unlocking calls all he wanted with nary a thought about records or valiidyt. Could it be made to be incumbent on the Data class to check...once the lock was obtained...as to whether the record was still valid or not? Once "owned", in a locked sense, then Data could make up it's own mind about what to do if he got an invalid record, like throw a RecordNotFoundException or something after unlocking it....?
</devils-advocacy>

I dunno....it just seems to me with the static reference to Data removed, you'd free up LockManager to be used by other classes outside DBAccess and it'd be one less little arrow I'd need to draw on my legal pad here. That's my biggest problem, no room left on the page.

...but if this makes no sense based on what you're got, ignore me. Remember, I'm still in the almost-no-design, certainly-no-code-blue-sky stage, so everything works correctly, cleanly and perfectly in my B&S system.

Good luck,
Richard
Alan,

I'm still in design phase for locking, so I came upon your description while trolling for ideas. Thank you for posting it in such easily digested detail.

I drug out a legal pad and #2 software-design-instrument and drew some boxes and arrows and I think I pretty much follow your design. One question I did have was about this comment in LockManager::lock():

When the thread is again in the running state it re-checks if the
record is locked.
It also re-checks that the record is still valid. This is important as it could have been deleted while we were waiting on it.



I follow your rationale here...I can see it but...it looks to me like this may be a bit of encapsulation leakage, unless I'm interpreting it incorrectly, which may well be the case. What I mean is that this seems to require that the LockManager have information about the concept of "valid" in data records, which seems a bit outside the very sleek and otherwise elegant design you've come up with for it dealing only with record numbers and locking. Which means, in an implementation sense, you have to supply something, not sure what...a data structure maybe...?..from your Data class to LockManager? Or am I just waaay out in the weeds somehere?

Thanks,
Richard