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

legality of over-riding lock/unlock methods

 
RJ Cox
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
RJ Cox
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
RJ Cox
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, thanks very much for your insight, especially the phrase that they won't care too much if a client has to wait. That was what was bugging me.
Will take the less convoluted route for now.
Thanks
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic