Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Why lockRecord and unlock are necessary

 
Travis McLeskey
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now that I know the answer, it seems pretty obvious, but for about a day, I was confused about why the lockRecord() and unlock() methods are necessary in the Data.java interface.

I thought, why not just make the deleteRecord() and modifyRecord() methods atomic...they can implement their locking internally. As long as the methods don't have weird results when they run simultaneously on the same record, what's the problem? Here's an example of why it's a problem:

What if two threads want to increment a value in a certain record? They do it by getting a copy of the current value in the record, incrementing the copy, and then writing the copy back to the database. If there is no locking outside the modify/delete records, then they might run simultaneously, getting the same value and writing back the same value. The end result is that the value is incremented once, instead of twice like it should have been. Bracketing the reads and writes in lock/unlock calls prevents this.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Travis,

Welcome to JavaRanch and this forum.

I agree with what you have written.

I take it that your business method modifyRecord (which calls Data's update method) is on the server. Having your business method as an atomic method will also reduce concurrency.

Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic