0004252: Concurrent Access (Mid-Air Collision)

Notes
(0013656) Julian (reporter) 2011-02-17 10:56	Reminder sent to: Eloff Erik, as far is i know you implemented "login recovery after session timeout" and "navigating away without saving" feature. did you then also make thoughts about this issue ?

(0013667) Eloff (reporter) 2011-02-17 23:02	Yes, I implemented that feature, but I did not think about multiple access to the same item concurrently

(0013688) fman (administrator) 2011-02-19 10:43 edited on: 2011-02-19 10:53	links that may be can help (can not give warranties). http://jim-mcbeath.blogspot.com/2009/02/concurrent-editing-without-locking.html [^] http://en.wikipedia.org/wiki/Optimistic_concurrency_control [^] FROM: http://stackoverflow.com/questions/3564877/how-do-you-manage-concurrent-access-to-forms [^] "... Do something similar to what is done in many version control systems. Allow anyone to edit the data. When the user submits the form, the database is checked for changes. If the record has not been changed prior to this submission, allow it as usual. If both changes are the same, ignore the incoming (now redundant) change. If the second change is different from the first, the record is now in conflict. The user is presented with a new form, which indicates which fields were changed by the conflicting update. It is then the user's responsibility to resolve the conflict (by updating both sets of changes), or to allow the existing update to stand. "

(0017538) fman (administrator) 2012-09-21 21:06 edited on: 2012-09-22 07:18	http://www.martinjacob.info/tag/optimistic-concurrency-control/ [^] http://permalink.gmane.org/gmane.comp.db.adodb.general/314 [^] http://etutorials.org/Programming/Java+data+objects/Chapter+15.+Optimistic+Transactions/15.1+Verification+at+Commit/ [^] http://userscripts.org/jetpacks/27 [^]

(0017541) fman (administrator) 2012-09-22 07:40	This can be the approach (taken from stack overflow) We put in a very simple optimistic locking scheme that works like this: * every table has a last_update_date field in it * when the form is created the last_update_date for the record is stored in a hidden input field when the form is POSTED the server checks the last_update_date in the database against the date in the hidden input field. If they match, then no one else has changed the record since the form was created so the system updates the data. *If they don't match, then someone else has changed the record since the form was created. The system sends the user back to the form edit page and tells the user that someone else edited the record and they must reapply their changes.

(0017542) fman (administrator) 2012-09-22 07:43	Or: The simplest method is to format your update statement to include the datetime when the record was last updated. For example: UPDATE my_table SET my_column = new_val WHERE last_updated = <datetime when record was pulled from the db> This way the update only succeeds if no one else has changed the record since the last read. You can message to the user on conflict by checking if the update suceeded via a SELECT after the UPDATE.

Issue History
Date Modified	Username	Field	Change
2011-02-17 10:54	Julian	New Issue
2011-02-17 10:56	Julian	Note Added: 0013656
2011-02-17 23:02	Eloff	Note Added: 0013667
2011-02-19 10:43	fman	Note Added: 0013688
2011-02-19 10:45	fman	Note Edited: 0013688	View Revisions
2011-02-19 10:53	fman	Note Edited: 0013688	View Revisions
2011-02-19 10:55	fman	File Added: web_development_-_How_do_you_manage_concurrent_access_to_forms__.pdf
2011-02-20 15:52	fman	Product Version	1.9.2 (2011 Q2 - bug fixing) => 1.9.1 (bug fixing)
2011-08-31 12:40	Julian	Relationship added	has duplicate 0003191
2012-09-19 22:23	Julian	Relationship added	has duplicate 0005236
2012-09-21 21:06	fman	Note Added: 0017538
2012-09-21 21:08	fman	Note Edited: 0017538	View Revisions
2012-09-21 21:10	fman	Note Edited: 0017538	View Revisions
2012-09-22 07:18	fman	Note Edited: 0017538	View Revisions
2012-09-22 07:40	fman	Note Added: 0017541
2012-09-22 07:43	fman	Note Added: 0017542