File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes GUI / BLL - Record modified when altering alert 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 "GUI / BLL - Record modified when altering alert" Watch "GUI / BLL - Record modified when altering alert" New topic

GUI / BLL - Record modified when altering alert

Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Howdy Ranchers!

In my URLyBird I was thinking about informing user that between his read operation (the record he sees in the grid) and book operation, someone did something with the record.

In case the record was removed, there is no fear - I can just return RecordNotFoundException but in case update - I think the user should be informed that the record has been modified, because the one he see on the screen (let's say with price $250) could be changed to $1000 for a night - and he booked the room with price not he agreed to. Also this convers the situation in which the record was deleted and then new one was created (with the same record number if your reuse the already deleted records).

I was thinking about creating some kind of MD5/checksum/hashcode for the record the user read and send it to the book operation in service layer. Then in service layer:
- the record is locked,
- the record is read to get the actual version,
- the checksums are compared and if there is no match: unlock record and throw the RecordModifiedException to the GUI,
- the record was not updated.

The user must be informed about this situation and the record in grid must be refreshed.

The only problem is that the user might be prevented to update the record in infinity (if everytime he hits "book" button, someone other updates the record). I don't know if I should accept this situation.
If not, there is other way to solve it - after the records checksums match fail, the record is not unlocked but rather the user is informed about changes in the record. Then, he is presented with the changed one (grid refresh) and decide what to do. If he:
- cancels the operation - the lock is released,
- accepts to book the room - the record gets updated and lock is released.

The problem with this approach is that the user application might crashed and the lock has not been released. In this situation, the record is dead till the end of server execution.

What do you think guys?

Roel De Nijs

Joined: Jul 19, 2004
Posts: 8359

I think the approach is valid, but it is work which is not needed at all, because the assignment does not require this kind of functionality. Introducing functionality which is not required results (or may result) in:
- more bugs
- extra complexity
- more code to maintain
- ...

And in the end this extra code may not be used, because adding new records and updating old ones will never be implemented.

SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Hi Roel!

Thanks for pointing this - I've almost forgot that create/delete operations should not be even considered to happen at this point.

And even bigger thanks for reminding that even the update operation will not be performed (excluding customerID modification when booking)!

So, no more thinking about records hash comparing, refreshing, informing user about it, etc.
I agree. Here's the link:
subject: GUI / BLL - Record modified when altering alert
It's not a secret anymore!