Anonymous | Login | Signup for a new account | 2019-12-12 06:13 UTC | ![]() |
Main | My View | View Issues | Change Log | My Account |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
0004252 | TestLink | New Feature | public | 2011-02-17 10:54 | 2012-09-22 07:43 | ||||||||
Reporter | Julian | ||||||||||||
Assigned To | |||||||||||||
Priority | high | Severity | feature request | Reproducibility | N/A | ||||||||
Status | new | Resolution | open | ||||||||||
Platform | OS | OS Version | |||||||||||
Product Version | 1.9.1 (bug fixing) | ||||||||||||
Fixed in Version | |||||||||||||
Summary | 0004252: Concurrent Access (Mid-Air Collision) | ||||||||||||
Description | When 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 Information | Could not find an existing issue for this. | ||||||||||||
Tags | No tags attached. | ||||||||||||
Database (MySQL,Postgres,etc) | - | ||||||||||||
Browser | |||||||||||||
PHP Version | |||||||||||||
TestCaseID | |||||||||||||
QA Team - Task Workflow Status | |||||||||||||
Attached Files | ![]() | ||||||||||||
![]() |
|||||||||||
|
![]() |
|
(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. |
![]() |
|||
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 |