Two users updating the same record at the same time.
4 views
Skip to first unread message
dvoorhees49
Mar 18, 2009, 2:57:52 PM3/18/09
to VersionOne-users
A user in support added a Request. I went in to edit it (as I usually
do) and while I was working on it, the support rep went back in and
added more notes, etc. He saved his changes, but when I saved my
changes his changes were gone. I was able to use the audit feature to
bring up the Request as it looked after he finished it, but I he had
not called me to say “something weird is going on with VersionOne” we
would have missed it.
do) and while I was working on it, the support rep went back in and
added more notes, etc. He saved his changes, but when I saved my
changes his changes were gone. I was able to use the audit feature to
bring up the Request as it looked after he finished it, but I he had
not called me to say “something weird is going on with VersionOne” we
would have missed it.
Mark Crowe
Mar 18, 2009, 5:50:52 PM3/18/09
to versiono...@googlegroups.com
Let me know if I've misinterpreted the events you've described: It sounds like both users in this case were updating the description of the request at the same time, which led to this issue.
Typically, the natural flow of ownership helps to minimize overlap between people updating any one item at any given time. It is a very real consideration, though, so I'd like to clarify the behavior here a bit.
Within VersionOne, two users updating the same record at the same time is allowed and doesn't create any conflict. When I update the Priority of a Request, for example, the system will update only the Priority field when I save my change. There is no problem with one of my teammates updating the Description of that same request at the same time. Both of our changes are saved and the end result includes both updates.
A potential conflict can occur when two users are updating the same *field* on the same record at the same time. At the field level, the common "last in wins" rule applies. Even when this happens, there's no real difference in the end result if the updates are made to a field such as Priority or a Date that can carry only a single value anyway - the current value can only reflect one thing and this will be the last update that was made.
The real issue occurs only when the two users are both updating the same text field at the same time. In that case, the same field-level "last in wins" rule applies. That may or may not be the desired outcome depending on the changes being made.
Overall, it is very rare for a conflict to happen and actually have a meaningful impact as described. This does serve to warn us, though, that rare is not the same as impossible. It's always good practice to avoid keeping edit windows open for long periods of time before making updates - this will keep the chances of encountering such an issue to an absolute minimum.
- Mark
Typically, the natural flow of ownership helps to minimize overlap between people updating any one item at any given time. It is a very real consideration, though, so I'd like to clarify the behavior here a bit.
Within VersionOne, two users updating the same record at the same time is allowed and doesn't create any conflict. When I update the Priority of a Request, for example, the system will update only the Priority field when I save my change. There is no problem with one of my teammates updating the Description of that same request at the same time. Both of our changes are saved and the end result includes both updates.
A potential conflict can occur when two users are updating the same *field* on the same record at the same time. At the field level, the common "last in wins" rule applies. Even when this happens, there's no real difference in the end result if the updates are made to a field such as Priority or a Date that can carry only a single value anyway - the current value can only reflect one thing and this will be the last update that was made.
The real issue occurs only when the two users are both updating the same text field at the same time. In that case, the same field-level "last in wins" rule applies. That may or may not be the desired outcome depending on the changes being made.
Overall, it is very rare for a conflict to happen and actually have a meaningful impact as described. This does serve to warn us, though, that rare is not the same as impossible. It's always good practice to avoid keeping edit windows open for long periods of time before making updates - this will keep the chances of encountering such an issue to an absolute minimum.
- Mark
Reply all
Reply to author
Forward
0 new messages