This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S: Locking aproach Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S: Locking aproach" Watch "B&S: Locking aproach" New topic
Author

B&S: Locking aproach

Bodenstab Oliver
Ranch Hand

Joined: Mar 03, 2005
Posts: 47
Hallo,

i want to dicuss my locking aproach.

First i want to support the DBMain interface and the Data class from sun,
so i implenment my locking here. I delegate this to the LockManager (singleton).
Only the buisiness layer can access the data-layer not the client!
If the buisiness layer calls lock in the Data class, the data class give it to the LockManager and he stores the lock in a HashMap. After that, the buisiness layer do the update things and calls than the Data class unlock method.

The LockManager methods all synchronized!!!

I test this aproach and it work good, but evertime the unlock is called, the
notifyAll method wakes up all waiting threads. This is of course not the fastest implementation.



And now the big question

Is it enough to synchronize the LockManager methods to take care of concurrency and the assignment or do i have to do more???

Thanks for response

Oliver


SCJP
Lara McCarver
Ranch Hand

Joined: Dec 09, 2003
Posts: 118
It's fine to synchronize all your methods in the LockManager class, but there's more you have to do. Of course, you are probably only showing us a fragment of your code, but still... the DBMain lock() and unlock() methods are supposed to throw a RecordNotFoundException if the record isn't found, and the LockManager doesn't throw that exception.

Here are some other things to think about: What happens if someone calls lock() for a record and then calls delete() for that record? How does the lock manager know that the deleted record is no longer valid? And if someone creates a record, how does the lock manager know to add that record to its list of lockable records? These are some of the questions that I have been mulling over for the past month or two. Good luck!
Daniel Dalton
Ranch Hand

Joined: Mar 20, 2005
Posts: 146
Hi Lara - good questions.

Personally, my lock manager does not even have a list of lockable records. It simply manages the association between a locked key and the client that locked it.

Your lock method in the Data class can just call the read() method to determine whether the record is valid or not - Your read() method will throw the required RecordNotFoundException.
Robert Hayes
Ranch Hand

Joined: Oct 24, 2004
Posts: 116
Doesn't your DBMain interface instruct you to give up the CPU? (my project does...)

If you synchronize your lock() method proper, threads will block on it. Blocking does not give up the CPU.

--Robert
Bodenstab Oliver
Ranch Hand

Joined: Mar 03, 2005
Posts: 47
Hallo,

thanks for so many replies

Here are some other things to think about: What happens if someone calls lock() for a record and then calls delete() for that record? How does the lock manager know that the deleted record is no longer valid?

I think, also deleted record must be lockable. Because, if you want to create a new contractor you must lock a record first. This can also be an deleted record.

Personally, my lock manager does not even have a list of lockable records. It simply manages the association between a locked key and the client that locked it.

I do it the same way.

Doesn't your DBMain interface instruct you to give up the CPU? (my project does...)

I think, the methods only block it for the time till they end. Of course,
synchronizing methods take more cpu time than synchronizing Objects. But because of i only hold the locked records by recNo/Client i can't lock the recNo (which is of type Integer). Every time i create an Integer there will be a new Object.
Daniel Dalton
Ranch Hand

Joined: Mar 20, 2005
Posts: 146

I think, also deleted record must be lockable. Because, if you want to create a new contractor you must lock a record first. This can also be an deleted record.


I'd take care with that assumption - my lock record says it throws RecordNotFoundException. Further down in my instructions, it says that any methods that throw RecordNotFoundException should do so if a specified record does not exist or is markd as deleted in the database file. Assuming your instructions are similar, how then are you going to lock the record?
Bodenstab Oliver
Ranch Hand

Joined: Mar 03, 2005
Posts: 47
Hallo Daniel,

you are absulutly right. I forgot this "should" instruction.
But how can you insert a new record and be sure, that at the same time, no other user inserts another record at the same position of the file.



Oliver
Daniel Dalton
Ranch Hand

Joined: Mar 20, 2005
Posts: 146
I guess it depends on your approach. In my instructions, it's up to the create method itself to determine the record number to return. My create method calls a synchronized helper method on a singleton object of another class to do the actual file handling. Hence two threads can't get the same record number.
Bodenstab Oliver
Ranch Hand

Joined: Mar 03, 2005
Posts: 47
Hy Daniel,

i revised my locking code. I think, checking the delete flag with a helper class (Singleton), is necessary

Thanks for your advice
Jim Doyle
Ranch Hand

Joined: Jul 18, 2003
Posts: 36

I'm working on the same project. I've been picking away at it for
months now because I am fully employed on a contract. However, my entire
back end is finished (and unit tested ) and what remains is for me
to pick away at the front end. Though I wont give you details on what I've done, I will tell you what you need to consider in your design.

FYI - I'm an architect, but am doing this damn assignment because I paid
$250 for it years ago and I want the "Street Cred" of SCJD.

Looking at your ideas, you havent fully thought through ALL of the concurrency issues. They are subtle. You can expect to spend sizeable time
to get it right. You will be handsomely rewarded in intellectual value though, since you will get first hand experience in database internals.

Some things to think about, which will reveal issues with concurrency:

1. What happens if a thread calls lock() twice in a row?

2. Lets say you call lock(). Now you are wait()-ing because someone else
holds the lock. What happens when your wait ends and you are woken back
up? Is it possible that the other thread that you were waiting for did
a delete on that row?

3. Is there a primary (possibly composite) key for this table ??
3a. If there is a candidate key, what happens if you UPDATE a row and
the requested updates collide with the primary key? How can you
prevent this?
3b. Lets imagine you have two threads. One is INSERTING and the other is
UPDATEing. Is there a situation where the INSERT and the UPDATE
happen close enough that two rows end up in the table that create
a primary key violation? The race condition requires that the check
for key constraints race at the right time.


These are some things to think about. Deletes Racing Row Locks, Updates
and Inserts Racing each other, Updates (as well as inserts) causing Key
Violations.

Next, you might think about Row Locks as well as Table Locks to resolve
these races. However, whenever you have two (or more threads) and two (or
more) locks, there is a possibility of deadlock. So, you must design your
locking protocol to escalate, as well as be deadlock free. Design wise,
your database needs to be sequentially consistent ; so, as a start, all
reads and writes need to be atomic.

This is GOOD STUFF and the only place you get to play with this (other
than the SCJD) is a good, solid graduate level course in Database Theory
that includes a Systems approach. Finding courses taught from this perspective is tough - usually only full-time day programs at big campuses.

It sucks writing this, but doing it JUST ONCE is rewarding as you may
never get a chance to do real systems level design once you move onto
J2EE and what not.

If you want true illumination - seek out "Principles of Transaction Processing" by Jim Gray. Everything you take for granted with CMP and
JTA is spelled out there.

-- Jim
Bodenstab Oliver
Ranch Hand

Joined: Mar 03, 2005
Posts: 47
Hallo Jim,

thank you very much for your ideas

Oliver
 
wood burning stoves
 
subject: B&S: Locking aproach
 
Similar Threads
URLybird
pls validate my locking strategy - all inputs are g8ly appreciated. (URLyBird)
NX: Looking for comments on my lock/unlock methods
About:My URLyBird1.3.2 Locking
My design, File locking, record locking,please help!