• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Lock check in Update and Delete

 
Jon Pengelly
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I have specified a locking contract for anybody using my Data class. It is like many people's implementations :
Lock record
Do whatever you want to the record
Unlock record
I am happy with this approach even though there is the flaw that we cannot guarantee a programmer using Data will follow this contract. I was just going to document this and acknowledge the flaw.
However, after thinking about this today I think that I should add a check to the update and delete methods to ensure that this record is in the lockedRecords map and that the owner of this record is the current thread.
This is pretty good because it means that even though we have specified the lock contract we are still protecting the database from updates and deletes without having locked the record.
And so my questions are:
Is this what everyone else is doing and it is the case that I was just a bit slow on the uptake with this one?
Or maybe I haven't thought this one through and people can spot a flaw in this idea?
Thanks for any comments,
Jonathan
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jon,
However, after thinking about this today I think that I should add a check to the update and delete methods to ensure that this record is in the lockedRecords map and that the owner of this record is the current thread.

I guess it may depend on your instructions, but in mines yes, such a check is mandatory (both update() and delete() throw SecurityException in case the record is not locked or locked by someone else).
Now depending on your design, the current thread may (business layer server-side) or may not (business layer client-side) represent the owner of the lock. If every client owns its own Data instance, the latter could play the role of lock's owner.
Regards,
Phil.
[ February 20, 2004: Message edited by: Philippe Maquet ]
 
Jon Pengelly
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the reply Phil.
I don't have the SecurityException defined in my DBMain interface but I think I will implement some sort of unchecked SecurityException to handle this case.
Cheers,
Jonathan
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
SecurityException *is* and unchecked one...
I think it's safe to do it (as far as you document it of course).
Regards,
Phil.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic