Radicore Forum - RDF feed
https://forum.radicore.org/index.php
Concurrency / freshness of data objects
https://forum.radicore.org/index.phpindex.php?t=rview&goto=419&th=131#msg_419
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]]>Kiple2006-11-23T21:13:02-00:00Re: Concurrency / freshness of data objects
https://forum.radicore.org/index.phpindex.php?t=rview&goto=421&th=131#msg_421
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?"]]>AJM2006-11-23T22:39:31-00:00Re: Concurrency / freshness of data objects
https://forum.radicore.org/index.phpindex.php?t=rview&goto=439&th=131#msg_439
Please refer to http://www.tonymarston.net/php-mysql/infrastructure-faq.html #faq70 for details.]]>AJM2006-12-05T11:14:53-00:00