| Concurrency / freshness of data objects [message #419] |
Thu, 23 November 2006 16:13  |
Kiple
Messages: 5
Registered: November 2006
Location: Surrey, UK
|
Junior Member |
|
|
Hi,
First let me say how much I like the Framework, diving into the code has been a good learning experience.
I think I may have missed something. One of the key problems is the risk that the data you are editing is not the latest and someone else has changed it. The delay between when you read the data to start editing and the point when you commit the changes can be substantial in computer terms.
I have seen some business objects that check for changes before the update or delete process and fail if there has been an update.
I can't see how Radicode protects against this. Is it locking at the business rules level?
Regards
Kiple
|
|
|
|
| Re: Concurrency / freshness of data objects [message #421 is a reply to message #419] |
Thu, 23 November 2006 17:39  |
AJM
Messages: 2371
Registered: April 2006
Location: Surrey, UK
|
Senior Member |
|
|
Generally speaking two people should not be updating the same information on the same object at the same time. If they are then there is something wrong with your administrative procedures.
The simple solution is to allow both updates, so which ever update is applied last is the one that 'sticks'.
It would be possible to cause the second update to fail if any data has changed between the 'read' and the 'update', but in my long experience this has rarely been requested by customers, and in those few cases were it has it has actually caused more problems than it solves.
In short, Radicore does not have any built-in method to protect against such updates. The real question should be "why would two different people be trying to update the same record at the same time?"
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
|
|
Radicore Forum
Search
Help
Members
Register
Login
Home
