• 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
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

Locking strategy and thread safety - similar but not the same?

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,

I've read many of the threading related (ahem) threads, which have really helped me consider angles I had previously overlooked. One such angle I'm mulling over is the relationship between the locking strategy (as defined in the provided interface) and the requirement that the application be thread safe. Are they the same, or just similar?

My own view on this is that they only similar. The locking methods in the provided interface are offered almost out of convienence to the caller. The other methods (create, update, find, etc.) should be thread safe with out the help of lock, unlock, and isLocked. The locking methods are there to ensure that the following situation does not occur:

2 clients and 1 db/server
Both clients wish to book the same unbooked record
They both execute the booking almost at the same time.
The locking methods ensure that no double booking occurs.


I think this ties in with the argument about whether to expose the locking fuctionality to the client. Of course there is no right answer, but I think the locking functionality/responsibility should be propagated up to the client rather than say employing the adapter pattern at the db level.

Anyone hava any thoughts on this?
 
Ranch Hand
Posts: 92
Android Eclipse IDE Suse
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Your assumption is correct.
With the locking mechanism you guarantee that only one client at a time can update or delete a record.
Suppose two clients want to delete record 4 for example.
Client A locks record 4 (suppose he gets first CPU).
Client B wants to lock record 4 but being locked by Client A it is forced to wait.
Client A deletes record 4 and then releases the lock.
At this time client B could gain the lock on record 4 but since it is already deleted he will only get a RecordNotFoundException.

Andrew explained this several times on this forum. I hope that I understood it correctly.

Regards,

Romeo
reply
    Bookmark Topic Watch Topic
  • New Topic