• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

B&S: Locking aproach

 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 146
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 146
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hy Daniel,

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

Thanks for your advice
 
Ranch Hand
Posts: 36
IBM DB2 Netbeans IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hallo Jim,

thank you very much for your ideas

Oliver
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic