• 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

UrlyBird Locking - my story so far

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
reply
    Bookmark Topic Watch Topic
  • New Topic