This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "CRV2 RevCodePersistentAntiPatterndotNet"
(Created page with "== Anti-Pattern #1: Tight Coupling == == Anti-Pattern #2: Assuming Static Requirements == == Anti-Pattern #3: Mishandled Concurrency == == Anti-Pattern #4: Stateful Services =...") |
|||
| Line 1: | Line 1: | ||
| − | = | + | =.NET Anti-Pattern: Mishandled Concurrency = |
| − | + | ||
| − | == | + | The correct concurrency management techniques is absolutely necessary in order to guarantee data integrity. A way to implement proper concurrency consists in creating a concurrency token which will be checked from the moment the entity object in the database was read until the moment when the submission will be executed. Prior to commit the final changes, the application must execute control where the concurrency token will be compared. If the token differs, conclusions can be drawn that indeed the data has been changed by another user. |
| − | + | ||
| − | + | The Entity Framework supports optimistic concurrency, unfortunately exceptions derived from errors encountered between the updates are not automatically handled, neither this will protect your data from corrupting. | |
| − | + | ||
| + | The recommended pattern in this case consists in "making a copy of the entity on the client and send back both the original version unmodified and the modified version or to write the client in such a way that it does not modify the concurrency token".(Simmons, 2009) | ||
| + | |||
| + | == References == | ||
| + | Simmons, D. (2009, June ). Anti-Patterns To Avoid In N-Tier Applications. MSDN Magazine. Retrieved from http://msdn.microsoft.com/en-us/magazine/dd882522.aspx#id0420025 | ||
Revision as of 01:48, 18 June 2013
.NET Anti-Pattern: Mishandled Concurrency
The correct concurrency management techniques is absolutely necessary in order to guarantee data integrity. A way to implement proper concurrency consists in creating a concurrency token which will be checked from the moment the entity object in the database was read until the moment when the submission will be executed. Prior to commit the final changes, the application must execute control where the concurrency token will be compared. If the token differs, conclusions can be drawn that indeed the data has been changed by another user.
The Entity Framework supports optimistic concurrency, unfortunately exceptions derived from errors encountered between the updates are not automatically handled, neither this will protect your data from corrupting.
The recommended pattern in this case consists in "making a copy of the entity on the client and send back both the original version unmodified and the modified version or to write the client in such a way that it does not modify the concurrency token".(Simmons, 2009)
References
Simmons, D. (2009, June ). Anti-Patterns To Avoid In N-Tier Applications. MSDN Magazine. Retrieved from http://msdn.microsoft.com/en-us/magazine/dd882522.aspx#id0420025
