Quick question on the legality of overriding lock/unlock methods: I want to implement the lock/unlock algorithm by using a reader AND a writer lock. (The project specifies a lock/unlock method, but does not distinguish between reading/writing.) But to implement my preferred method of using reader/writer locks, I think I need to subclass Data and then provide a lockReader and lockWriter set of methods (as well as unLockReader and unLockWriter). This is to maintain the original lock/unlock signatures of the Data class. I can implement the writer lock logic in the parent Data class' lock/unlock methods, and the reader logic in the subclass' lockReader/unLockReader methods. The subclass' lockWriter and unLockWriter would simply call the parent's lock/unlock methods. The only problem I see is that the original lock/unlock methods in the parent class should not be called directly by any other class than the child class in order to take advantage of the reader/writer granularity. Just wondered if this is too kludgey of a solution and/or if I should skip the concept of having reader and writer locks. Thanks RJ
Can't really put an opinion of Kluggy. But it seems to be some added "terminology" in your solution. A lockReader, lockWriter. What are they? what are their purposes. Do they have to be that way. I am not saying this is a bad way, it just seems to be a little more than you might need. Mark
Well the purpose of the reader/writer locks is to allow several readers to access a given record simultaneously as long as there is only reading going on for that record. I don't want any readers to access a given record if that record is being written. If a writer wants to access a given same record, then he must wait until the readers are finished with that record. On the reverse side, if a writer is busy writing a record, then no readers nor writers should be allowed to access that record until the busy writer if finished with it. If I don't use both reader and writer, it seems like multiple clients doing a variety of reading and writing may unneccessarily have to wait. Hope that makes sense, it's just to allow writers to know when readers are accessing a record (and so prevents him from writing the record) and for readers to know if any writers are accessing a record (which would prevent them from reading the record). PS -- Kludgey (kloogee) (adj.) Non-standard and odd implementation, but one that works. Can be applied to describe Rube Goldberg type devices; used often by people touting at windmills.
Well, I think it's a cool idea. I haven't heard of any going that far. It is a nice feature for a production application, but it might be a little overkill for the assignment. They don't care if clients have to wait for a record to be unlocked. And if you use the Unreferenced interface it won't unlock records there for 15 minutes. That's also what I mean by not having a complete answer for you. I like the concept, just think it might be a little more than needed. But I don't know how they would grade that. Mark