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

tracking lock owner - is it necessary

 
Gytis Jakutonis
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,
in many posts I see design choices to either change Suns interfaces or add separate database maangement class in order to support lock owner tracking. This safes us from malicious client, which could modify record withouth owning a lock. Are there any developer, whi was successfull withot tracking lock onwers(as I'm not going to implementi it)?
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Gytis,
In your instructions, in the provided interface, in the section describing the lock method, do you have instructions similar to the following?

// Locks a record so that it can only be updated or deleted by this client.

(Highlighting is mine)
If you do not track lock ownership, how can you ensure you meet this criteria?
I know it is possible to write a server that does not need this functionality, but that is not the point. The instructions require the Data class to provide this functionality.
Regards, Andrew
 
Gytis Jakutonis
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,
yes, I have this sentence in my instructions document. However Suns DBMain interface does not support client idetifier for lock(), unlock(), update() and delete(). And I'm not sure that Sun wants us to develop DBMain(or Data) per client system, but there is no other way to identify client.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Gytis,
I think you just agreed that having an instance of the Data class for each connected client will allow you to track who owns the locks, thereby meeting the instruction.
But you feel this is undesirable? Why?
If you can justify your decision as to why you should not do this, then you could put that justification in your design decisions document. I do not know whether it would be accepted or not, but you could try.
I would remind you that locking is worth 20% of the assignments marks, so I personally feel that you need to do everything you can to meet Sun's requirements.
Regards, Andrew
 
Gytis Jakutonis
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Andrew, I think I'll stay with my design wich tracks lock owner. As for Data per client solution, I've just figured out that I could implement Data per request solution(which is simplier I guess), since my DBMain interface is not published for clients(this decision is off topic ). Thanks.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic