|
I spoke with Mike from Atlassian about this when I purchased JIRA. I asked about how they handle locking. JIRA appears to be using the "optimistic" locking mechanism, which basically means that it assumes the update can take place, and if something happens during the update where the state of the issue no longer allows the update, it does not proceed. I haven't tested it much myself, but I'm hoping Atlassian has a better answer. I did do a couple of tests (like updating an issue I deleted from another workstation, or trying to perform a workflow action against an issue that is no longer valid because of a change from another session). In each case, an error was raised that the operation could not be completed. As to two simultaneous edits, of course one of the updates would be lost - the one completed first, right?
Exactly !
We have 65 persons working with JIRA and it happens 2-3 times lately to have simultaneous edits and one loose all his changes !! I don't think it's acceptable.... I think there should be AT LEAST a message informing the user that the record was changed during editing session and that some data can be lost ! Based on the tests I made, it seems like most conflicting cases are around the <Edit issue> problem. If Atlassian can fix this one, I think we will have 95% job done !! This absolutely needs to be handled. Some of our customers are raising doubts about JIra because of this.
I have a lot of experience with locking in client/server and web applications in the development of software - mostly accounting software, but also some document management stuff. In order to provide the kind of locking you're after, it sounds like it would be a major change to the structure of JIRA from optimistic to pessimistic locking. I don't see that happening
 . Usually, the rules dictate that if the edits were permissible by 2 people one after the other, then it doesn't matter if they are done concurrently, since the second would have over-written the other's changes anyway. I am guessing the reason this isn't working for you is because one person is updating one set of fields (let's say priority, due date), and another is editing another set of fields (let's say testing strategy, etc.). In this case, I could see how the person updating testing strategy would inadvertently re-set the priority and due date back to what it was when they loaded the issue, and lose the changes the other user made. In systems where pessimistic locking (preventing others from updating a record being edited by someone else), this scenario was generally avoided by only updating the fields which were changed, rather than the whole record. I guess JIRA is doing the latter, based on your comments.Since JIRA maintains a last updated field, I guess the only reasonable option would be to issue a warning on update if the last updated field was changed (or just another change history record was added) since the record was loaded. Anyway, Stephane, perhaps you could elaborate on your use case so Atlassian would better understand the nature of your usage. In my installations, I would find it rare for 2 people to be editing the same issue at the same time. In the meantime, I'll vote for the issue  This one is really important for me as well. I'm preparing a case to move from OTRS to JIRA and this issue is something I cannot sweep under the carpet.
Suppose a team lead just had a meeting with Sales and Support and made a list of enhancements and fixes planned for a release. He goes back to his PC and starts setting the "fix for" versions. At the same time, Sales tells a prospect "your killer feature will be included in version 1.1.1.2". And a developer (who opened the issue before the team lead updated it) enters some ideas he has, for implementing the feature, in the issue and saves it. Do I understand correctly that suddenly the issue is not scheduled for 1.1.1.2 anymore ? If so, please please please put this in the roadmap for the next upcoming release I don't think it's necessary to switch to pessimistic locking though. Just use a timestamp or something like that and - before updating an issue - check whether someone else updated it before you. If so, just show an error message "another user updated this issue before you, please reload" (or something similar Of course that's not perfect, perhaps it would even be a temporary solution, but its WAY better than losing data, because you know lots of things can go wrong as a result of losing data (for instance, that feature we promised to a prospect is accidentally not included in the release and the prospect decides to "walk away"). I just (inadvertently) had the same issue to be re-opened in two tabs. So, when I completed the second one, I got an error like
ERROR [atlassian.jira.workflow.SimpleWorkflowManager] An exception occurred com.opensymphony.workflow.InvalidActionException: Action 3 is invalid at com.opensymphony.workflow.AbstractWorkflow.doAction(AbstractWorkflow.java:528) ... I'm not sure this should be logged as an error. It's a normal situation when one user tried to update an issue's status when it had already been updated at another session.
If it's a normal situation, then why is it an exception ? Eric, that's exactly my point. It's OK that the user is presented with some sort of "Invalid action" message, but this situaton can easily arise and should not be logged in atlassian-jira.log as an ERROR.
I think that the real explanation here is that we do not do optimistic locking in JIRA. In the cases that Neal describes, workflow transition, we do check to see if the transition that is being requested makes sense for the issues current state. The workflow engine checks this condition and this is why you see an exception. We also show the user a more human readable message about this kind of error. In regards to issue updates and all other updates in JIRA we do not do any form of optimistic locking.
We are aware that this has the potential to clobber data and it is an issue that we would like to address at some time. The issue is that adding optimistic locking to an application that was not designed to do it is a non-trivial task and therefore requires a lot of time and effort to achieve. I can not say when this feature will find its way into a JIRA release but it is something we are aware of. From Beth Winslow Gregory (JSP-11971)
My concern is related to that in JSP-11971 but is also different. I'd be ok with optimistic locking if Jira assessed which fields a user Again, the issue is that Jira seems to compare the fields in the edit In my example, User 2 had no interest in the field customer quote, yet It seems that Jira should be determining which fields have been updated /beth Beth Winslow Gregory Atlassian, please review recently linked issues. I think all 3 are the same ones, so maybe we can just pick this one as the master?
Neal,
Thanks. I have taken note of the linked issues. Cheers, This is very important to us. I am preparing to demo JIRA as a replacement for our current system, and without this we have a show stopper.
Please consider this for the next release Hi Malathi,
The situation has not changed in 3.11 or 3.12, however, we are planning to attack this. For more information please see: Cheers, |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Task
Open
Major
Control Concurrency for Update Functions in JIRA
I am a consultant and we suggest JIRA as the tool for all the development cycle but they do have concerns about that problem.