jQuery in Action, 2nd edition*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes UrlyBird Locking - my story so far 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 "UrlyBird Locking - my story so far" Watch "UrlyBird Locking - my story so far" New topic
Author

UrlyBird Locking - my story so far

Oliver Watkins
Greenhorn

Joined: Jul 21, 2008
Posts: 13
Heya... my first ever post. Been doing SCJD for 3 months now.

Anyway,

I am a bit puzzled about UrlyBird locking. Here is my journey so far..

The requirements state that you should lock/unlock records when updating them. This part is fine to me. I have the lock/unlock in place, and there is a straight forward wait()/notify() system in place. A hashmap keeps recNo's and timestamps..

Now once the lock is aquired, I update the record, and unlock. But the next problem I discovered was that if another client is updating ANOTHER row at the same time (ie. nothing is being synchronized), then data corruption can occur because the single RandomAccessFile is having its pointer moved by two competing threads hence causing potential data corruption.

So anyway.. i thought I might as well synchronize on the RAF object during the update method. This works fine now. All updates, deletes etc. are atomic. You can update with a thousand threads on random records all at the same time and no data corruption occurs.

But then two things puzzled me,

a) Things seem a tad over synchronized. My lock and unlock methods are synchronized, and then when I call the update() method, the whole internals of the method are contained in a synchronize block, because I am synchronizing the RAF.

Performance wise I just think it's a bit rubbish. There is nothing between these three pieces of code. It's just synch, synch and synch. I just don't like it. I might as well chuck the whole thing into one synch block.

I am thinking of having a pool of RAF objects that can run simultaneously on different record updates, however, if they update the same record, then they do the wait() / notify() thing.

b) The Requirements are a bit bizarre. What puzzles me the most, is that the requirements state nothing about a user updating a record that has changed since the GUI read the record. This is really poor software design.

Client A can read record where customer is "", then Client B can update it so that its customer is "abc", and then Client A can update it so that its customer is "xyz".

This is pretty poor. Shouldn't Client A get a message or something saying "record has been updated. Do you wish to overwrite?". I really wish the assignment said something like this. Rather than the silly SecurityExcepton check, why not a RecordModifiedException ?

Anyway, that's where I am at the moment. Anyone have anything to add to this?

cheers

Olly
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Originally posted by Oliver Watkins:
b) The Requirements are a bit bizarre. What puzzles me the most, is that the requirements state nothing about a user updating a record that has changed since the GUI read the record. This is really poor software design.

Client A can read record where customer is "", then Client B can update it so that its customer is "abc", and then Client A can update it so that its customer is "xyz".

This is pretty poor. Shouldn't Client A get a message or something saying "record has been updated. Do you wish to overwrite?". I really wish the assignment said something like this. Rather than the silly SecurityExcepton check, why not a RecordModifiedException ?


Hi there!

Welcome to Javaranch!

For your 2nd comment, I can't remember if it was explicitly detailed in the requirements.. However, what I did was to allow changing the record only if the client's original data was a perfect match with the database.

In the client's original data was different, a popup was displayed.

By the way, it cannot be "poor design" because YOU are in charge of the design and should create the best design meeting the requirements!
If something is not a requirement, then it's not good or bad, it's just not a requirement.

To handle locking, I used a collection where threads would register (by adding a entry) to specify which record is "lock". This piece of code is synchronized. After the update is performed, then the client would "remove" itself from the collection, again in a synchronized block.

Hope this helps
Alex
[ July 23, 2008: Message edited by: Alex Belisle Turcot ]
Shengshuo Wu
Greenhorn

Joined: May 28, 2008
Posts: 6
Originally posted by Oliver Watkins:
...
b) The Requirements are a bit bizarre. What puzzles me the most, is that the requirements state nothing about a user updating a record that has changed since the GUI read the record. This is really poor software design.

Client A can read record where customer is "", then Client B can update it so that its customer is "abc", and then Client A can update it so that its customer is "xyz".

This is pretty poor. Shouldn't Client A get a message or something saying "record has been updated. Do you wish to overwrite?". I really wish the assignment said something like this. Rather than the silly SecurityExcepton check, why not a RecordModifiedException ?
...


Hi friend,

I think this is one of the issues that we are required to deal with for the scjd assignment. And you did find the problem and try to solve it. That's the purpose of this exam, isn't it?

-ssw
[ July 24, 2008: Message edited by: Shengshuo Wu ]

SCJP, SCWCD, SCJD
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11460
    
  94

Originally posted by Oliver Watkins:
Heya... my first ever post. Been doing SCJD for 3 months now.

Welcome!

Originally posted by Oliver Watkins:
So anyway.. i thought I might as well synchronize on the RAF object during the update method.

Hopefully not only on the update method

Originally posted by Oliver Watkins:
a) Things seem a tad over synchronized. My lock and unlock methods are synchronized, and then when I call the update() method, the whole internals of the method are contained in a synchronize block, because I am synchronizing the RAF.

But what are the lock and unlock methods synchronized on, and what is the update method synchronized on? Hint: if they are separate objects, then somebody can be acquiring a lock at the same time that somebody else is performing an update.

Originally posted by Oliver Watkins:
Performance wise I just think it's a bit rubbish. There is nothing between these three pieces of code. It's just synch, synch and synch. I just don't like it. I might as well chuck the whole thing into one synch block.

But they are totally separate methods. There are no rules in the instructions that say that I can't obtain a lock and go to lunch and an hour later unlock my record without having done an update. And there is nothing in the instructions that would stop other clients from updating different records during that hour.

Originally posted by Oliver Watkins:
b) The Requirements are a bit bizarre. What puzzles me the most, is that the requirements state nothing about a user updating a record that has changed since the GUI read the record. This is really poor software design.

And here is where we get to see your thinking as a developer and not a programmer. A programmer will blindly follow instructions even if they result in an unusable product. A developer will think things through and make design decisions (and hopefully document them).

Originally posted by Oliver Watkins:
Client A can read record where customer is "", then Client B can update it so that its customer is "abc", and then Client A can update it so that its customer is "xyz".

Not if you develop a solution that stops this from happening! See also: JavaRanch SCJD FAQ entry on Why do we have lock() methods in the Data class?

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: UrlyBird Locking - my story so far