Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

URLyBird: Concurrent modification of records - How to deal with it?

 
Alexander Duenisch
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ranchers

i'm doing URLyBird (v. 1.1.3). Currently i'm having a hard time figuring out, how to implement the client's business logic. The assignment paper requires my UI ...
- "to allow the user to search for all the records, or for records where
the name and/or location fields exactly match values specified by the
user"
- "to allow the user to book a selected record, updating the database
accordingly"

Now i'm wondering in how far i am supposed to deal with the special issues of concurrent access (that are not already covered by record locking). For example:

1. client A searches for all the records
2. client B books record no. 11
3. client A tries to book the same record (not knowing that B already did)

How do i deal with this, if at all. The assignment doesn't specifically make this a requirement. However, i'm not certain if this isn't a general prerequisite.

One idea i had, was to make the client regularly poll the server for recent changes. Another approach i came up with is to have a member variable called 'lastModified' in my Record class, which i can check and throw an Exception if a client tries to book a record that was modified after it was retrieved by that client.
Both solutions appear to be a little excessive.

What do you think?
[ April 28, 2008: Message edited by: Alexander D�nisch ]
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You will need to implement a mechanism to make sure a client has not changed a record by the time another client tries to update it.

For instance:

Client A reads the record and saves a copy of it.
Client B reads the record and saves a copy of it.
Client B locks the record
Client B checks the record has not been updated by comparing the values of the original record with those of the saved one.
Client B updates the record with new values.
Client B unlocks the record
Client A locks the record
Client A checks whether the record has been modified.
Client A throws ConcurrentModificationException("The record has already been updated by another client")

[ April 28, 2008: Message edited by: Edwin Dalorzo ]
 
Joe Richard
Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alexander,

I didn't try copying the data to every GUI and updating it there. I created the Data object as a singleton and use that to update the database. The server is the only object allowed to update the database. Only one object updating the database made it easier to control what happened and how it happens. The GUI just displays the recent view of the records form the last communication with the server.
 
Alexander Duenisch
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I didn't try copying the data to every GUI and updating it there. I created the Data object as a singleton and use that to update the database. The server is the only object allowed to update the database.


I did it exactly the same way.


The GUI just displays the recent view of the records form the last communication with the server.


That's exactly the problem here.
Clients don't get notified, when one client changes a record on the server. This means, that some of them might have obsolete data in their GUI, depending on whether the last communication with the server happened before or after the change. In the end, a client might book a record (i.e. a hotel room) without knowing, that it has already been booked by another client.

The assignment paper doesn't require me to implement any form of client authentication, so one could deduce that it is also acceptable to have clients overwrite each others bookings. But somehow that doesn't seem right.

For that reason i followed Edwin's recommendation to throw ConcurrentModificationException if the described scenario occurs. To me, this seems like the best and simplest solution.
[ May 01, 2008: Message edited by: Alexander D�nisch ]
 
Joe Richard
Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alexander,

I recommend using some design patterns with the project. There are a lot of books on design patterns available, you can probably find some very good books from previous post within this forum. I used "HEAD FIRST DESIGN PATTERNS" I found the observer pattern worked for me.
 
Alexander Duenisch
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To use the Observer/Observable Pattern in this context, you would need to open a server socket on the client, so the server can propagate changes on data back to all clients. Maybe this is not such a bad idea as it appears to be at first glance.

Another approach would be to use datagram sockets (UDP) for broadcasting changes to the clients. However, i'm not sure if this is permitted by the rules of the assigment. My assigment paper doesn't explicitly ban ("must not use ...") the use of datagram sockets. But in his book, Andrew Monkhouse discourages from the use of datagram sockets (2nd edition, page 202), arguing that "the requirements of the exam tend to be vague regrading this point".

However, the requirements of the exam are being vague about almost everything. So i've taken up the position, that all is permitted unless it's explicitly banned.
[ May 02, 2008: Message edited by: Alexander D�nisch ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic