Fog Creek Software
Discussion Board

Is FogBugz concurrency-safe?

Hi Folks,

  I am wondering if FB can handle simultaneosly editing of the same bug. I am facing the following problem daily:

  A person is editing a bug while another is assigning it to another person. The assignment is lost.

Please let me know what you think.


Alexandre B. Corrêa
Wednesday, February 12, 2003

You will never "lose" any fogbugz action, but if a person other than the bug owner attempts to edit a bug, its possible that one action may happen after another (in the order that you didn't anticipate).  The assignment will still be there, just not in the order you might have imagined.

Michael H. Pryor
Wednesday, February 12, 2003

Suggestion from an "outside programmer":

1. Keep bug 'assigned person' when editing the bug.
2. When saving the bug changes, verify if 'assigned person' has changed its value in database.
3. If the answer is yes, do not change assigned person, unless user has changed it in the current form.

Alexandre B. Corrêa
Wednesday, February 12, 2003

I think the point is 'consistency'.

FB, in my humble opinion, should lock bug# record an avoid other user to edit this record while changes are not commited.

Alexandre B. Corrêa
Wednesday, February 12, 2003

I meant '...and avoid...'

Alexandre B. Corrêa
Wednesday, February 12, 2003

Due to the non-connected state of the web, "locking" the records would get very hairy.  What would happen if you go to edit a bug and then close your browser?  Now the lock would have to "timeout" before another user could edit it...

Michael H. Pryor
Wednesday, February 12, 2003

The first suggestion though, is a good one to consider... We'll definitely keep it on the list for consideration in the next version.

Michael H. Pryor
Wednesday, February 12, 2003

Also, you may want to institute a policy that only the bug holder should be changing a bug.  If someone wants to "steal" a bug, they should assign it to themselves first.

Michael H. Pryor
Wednesday, February 12, 2003

I don't understand your suggestion about bug policy.

The user "editing" the bug maybe be just adding some text or attachement, he shouldn't need to "hold" the bug, because he didn't want to change the bug (Area, FixFor, Assignment, or whatelse), just contribute with some info.
The bad thing is that while doing that he can mess (undo) a assignment (and possibly other operations?) that was being done concurrently.
Of course, if two (or more) users concurrently change the same field FB can't do any better, that would be a real problem of bug editting policy.

* What is happening:

Users can, without intention or control, "undo" edit/assign operations done by other users.

* How to reproduce the problem:

For example, one user starts correcting a spelling problem in the bug title (using the edit function), some seconds later the manager wants to change the FixFor, Assignment and other fields (but not the title). The manager is quicker and finishes his operation first - then the user finishes his editing and (frustated) notices he have just "undone" the manager's editing...

* What should happen:

Perhaps there should be a simpler edit function just for this cases (adding text/attachments, or changing just one field)??
IMHO, Alexandre's suggestion is much better, because it can cover cases where one user really wants to change some bug field, while keeping the others unchanged.

Luciano R. M. Silva
Wednesday, March 05, 2003

  One possible solution for this is not to use a single lock for the whole bug. If you do this, then yes, you'll either lose operations or you'll need to wait until the lock is released to another user add/update info in the bug.

  Of course that this kind of locking is not acceptable, since FogBUGZ is suppose to be a multi-user environment. So IMHO (yet another) possible solution is to use:

  1) Finer locking: You guys could use different locks for different data structures (for different fields in bug-editing mode): Using fine-grained locks will make FogBUGZ more scalable and will prevent losing operations of unrelated fields;

  2) Read-write Locks: This approach is used by some operating systems to allow concurrent readers but only single writers, in which the user will get a read lock when it reads stuff, but when someone wants to write stuff, it'll have to get a write lock. This is useful for complex stuff (which usually takes a long time), like attachments and stuff like that. This will prevent the "deadlock until the lock times-out" if the user gets a lock and closes the browser;

  Kind Regards,


Felipe W Damasio
Friday, May 16, 2003

We'll here are my two cents on a possible fix. It is not a complete fix, but at least it will prevent data from being lost when two users decide to edit the same case.

Add a field to the table, for simplicity sake make it a date and call it LastUpdated. Every time an edit takes place this date will be set update with the server date. An integer could also be used, but I think the date might be a little better.

So basically:

- ASP reads record to be edited along with this date
- User makes changes
- User submits changes

On Submit
- Does the date in the ASP match the value stored in the DB?
  - If Yes, update the field first, then Apply changes
  - If No, Do not apply changes and let user know that someone else has already modified the file you are looking at.

Odin Ortiz
Friday, May 16, 2003

*  Recent Topics

*  Fog Creek Home