• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

tracking lock owner - is it necessary

 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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)?
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
A sonic boom would certainly ruin a giant souffle. But this tiny ad would protect it:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic