Compartilhar via

Questions on Concurrency Conflict Resolution

  • Artigo

There's been an e-mail thread going around in an internal Microsoft Business Framework (MBF) discussion list of the best way to handle concurrency conflicts.  Someone brought up the novel idea of asking users what they would like to happen.  So that's what I'm doing.

Currently in MBF we support two modes of concurrency which you can specify for each entity type: at the entity level and the property level.  Entity level concurrency will ensure that when you save an entity, all the property values of that entity must match what exists in the database in order for the save to succeed.  Property level concurrency will ensure that when you save an entity, only those properties which have been modified must match what exists in the database in order for the save to succeed.

Developer Questions:

  1. Are there other variations or modes such as timestamp that you would like to see?
  2. What kind of information do you want returned when a conflict exception occurs?
  3. In what ways do you want to be able to resolve a conflict?  For example, should there be a way to force the save to overwrite the database values?

User Questions:

  1. Part of MBF involves UI generation.  How do you want to interact with the UI to resolve conflicts?
  2. In order to avoid user interaction, would something like a user-defined rule-based method of resolving conflicts be useful?

Any feedback you can give will help the MBF team out.  Thanks.

Comments

  • Anonymous
    October 14, 2004
    The comment has been removed
  • Anonymous
    October 14, 2004
  1. Timestamp is fine
    2. Perhaps have (pre-configured) levels of information that can be returned.
    3. Leave it to the user on how to resolve, after all, the user is best judge of what needs to change/override.
  • Anonymous
    October 14, 2004
  1. Timestamp - or even more better - Versioned objects. Timestamps can lead to some problems with timezones, truncation of timestamps in some databases etc..
    Versioned objects will allow you to not keep entire object data - but implement optimistic locking. This will works with complex objects - as object can change value/version based on content of others tables - but you will not be able to detect this without checking all related tables/data.

    But timestamp based concurrency checks can confuse users - as somebody (User1) can edit tiny subset of object - while concurrent changes (by User2) will be done on another fields.
    So Property level concurrency potentialy good - but the object change can confuse User2 - because he has changed salary field to person who he think a CEO - but User1 found an typo and corrected his job position to Chief Software Architect. Thus object will fail IRS equal opportunity salary validation rules ;-)

    2. In perfect situation - I preffer to see custom ConcurentModificationException for each bussiness objects defined for CRUD.
    It must provide provide a way to obtain from database - for example last modification date/time, user from audit fields in bussiness object.
    It must be possible to catch it, perform some method calls magic and retry transaction with object values updated.

    3. User must see "that" was changed and by whom. This is major point of pain - then you do not see that was changed - but must make some desigions to retry or nope.
    Take a look - if there is no needs for user to make desigions - what is a reason to show him this error message ? You must retry automaticaly in this case.
    UI must be adopted for this. It must allow to see 3 values - values then you read object, values user has assigned and values currently in database. As well it will be nice to show in color that fields need user attention.
    Custom CM exception must provide all the information for this, potentialy with some help from helper/visualisation classes.

    I like your idea to provide a CRUD/UI framework.
    Your development goal must be something like 2-3 hours to create CRUD Windows application for 4-7 tables with complex relationships. All UI, DOA classes and database schema must be generated from UML XMI or from some database with metadata (you can import your XMI files into and/or edit all values manualy).
    Allow user to do some basic UI/validation/customisation tweaks - but do not force him to code.
    I hope you will be able to reach this goal ;-)

    P.S> If there any way to subscribe to this internal MBF discussion list ? Legal must not be a problem ;-)