Mantis Bugtracker          
testlink.org

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004252TestLinkNew Featurepublic2011-02-17 10:542012-09-22 07:43
ReporterJulian 
Assigned To 
PriorityhighSeverityfeature requestReproducibilityN/A
StatusnewResolutionopen 
PlatformOSOS Version
Product Version1.9.1 (bug fixing) 
Fixed in Version 
Summary0004252: Concurrent Access (Mid-Air Collision)
DescriptionWhen multiple persons are accessing the same requirement/requrirement spec/test case/test suite in edit-mode there is potential risk for data loss.

To solve this problem there needs to be some mechanism that warns users if item is already in edit-mode.

This warning is not as simple as it seems as the editing user might not continue work -> TIMEOUT is necessary.

After making some thoughts about this issue i tried to identify things to be done:

1. new DB table that stores items in edit mode (item,user,start_edit_time,idle_time, ...)
2. functions to modify this table
3. javascript support to reset idle_time (whenever user types -> reset timeout : compare to characters left function for text area custom fields)

Things to keep in mind:
- feature should not make problems in combination with "login recovery after session timeout" and "navigating away without saving" feature
- for requirement revisioning feature may not cause problems
- force edit should be possible because other user might have left and timeout could be too long to wait for
Additional InformationCould not find an existing issue for this.
TagsNo tags attached.
Database (MySQL,Postgres,etc)-
Browser
PHP Version
TestCaseID
QA Team - Task Workflow Status
Attached Filespdf file icon web_development_-_How_do_you_manage_concurrent_access_to_forms__.pdf [^] (243,215 bytes) 2011-02-19 10:55

- Relationships
has duplicate 0003191closedJulian Implement a lock when modifying test case 
has duplicate 0005236closed support for OCC or Mid-Air-Collision avoidance 

-  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



Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker