File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Help on this locking scenario Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Help on this locking scenario" Watch "Help on this locking scenario" New topic

Help on this locking scenario

chris bajada
Ranch Hand

Joined: Oct 16, 2006
Posts: 41

Wonder if you can help me on the following record locking scenario:

Thread 1 Locks record X (with intention to delete it).

Thread 2 waits on record X (with the intention to update it).

Thread 1 deletes record X.

* In the short time when Thread 1 deltes the record (and notfies), and Thread 2 gets the record, the following happens:

As soon as Thread 1 deletes the record,
Thread 3 creates a record which overwrites record X. (B&S requrirements state that if possible we re use deleted record locations)

Now Thread 2, gains lock on record X... and updates the info of record X with *old* information- As Thread 2 did not know that while it was waiting for record X, the information had changed.

Do you have an idea how this can be solved? I wish to find a way to have Thread 2 throw an exeption back to the client if this case happens.


Michael Vargenstien
Ranch Hand

Joined: Jan 27, 2007
Posts: 61
Hey Chris,

I chose to encapsulate some private methods that are used by both the update, create use cases. So what this means is that when a record is updated or deleted, the database is "checked" to see if the data was deleted FIRST before attempting to update the record or create it. Make sure your methods are thread safe (only what absolutely needs to be thread safe.) If this is the case then throw a RecordNotFoundException and recover your application in the catch clause. This performs an internal check and removes the need for this situation to arise. Also, if you haven't done it already take a look at JDK 1.5 concurrent packages. They have some pretty neat stuff in there like WriteLocks/ReadLocks.

GLuck. d Luck!
Khaled Mahmoud
Ranch Hand

Joined: Jul 15, 2006
Posts: 361
First : Your system will perform the update functionality
in two separate calls (Lock Then Update).
This means that the client (user of the application) will first lock the record then update it.

Second : Regarding your case about that a thread might end up updating a record other than the record it wants to update, I have done the following :

For a client to lock a record, certainly he should have had read that record before.Now when this client wants to lock this record,read the value of this record again and also lock it. If the new value is different from the old value, display a warning to the user that this record has been changed,
and update its value in whatever GUI widget used to display its value.

This solution will include the two cases :
1- The record you want to lock has been deleted and then recreated
2- The record you want to lock has been updated.

Best luck

Life is the biggest school
Lucy Hummel
Ranch Hand

Joined: Apr 07, 2005
Posts: 232
Hi Chris,

As Khaled already stressed out, that a GUI works with old data is a common use case. So the idea to inform the client that the database entry has been changed, is a good choice in my opinion. Furhtermore, to re-read the database entry and update the GUI with the lastest database entries is a good strategy.

Br, Lucy

----------------------------------<br />| SCJP, SCWCD, SCBCD, SCEA, SCJD |<br />----------------------------------
chris bajada
Ranch Hand

Joined: Oct 16, 2006
Posts: 41
Thank you all for your suggestions. Most probably i'll opt for matching the GUI info with that of the db file before carrying out a transaction, and showing the client a JDialog box that the db has changed (if it changes) and refresh it like you told me.


I agree. Here's the link:
subject: Help on this locking scenario
It's not a secret anymore!