Uploaded image for project: 'MidPoint'
  1. MidPoint
  2. MID-5305

Resource update operation not always relative



    • Type: Bug
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 4.1
    • Component/s: None
    • Labels:
    • Subscription:
      Active subscription


      I know this is hard topic, at the edge of bug/enhancement. But since mp is relative changes oriented system I would love to see it working flawlessly. In LDAP connector, or custom connector when relative update methods are implemented (UpdateAttributeValuesOp or newer UpdateDeltaOp), there are moments when midPoint reads (old) data from the resource right before it calculates the delta which is send to the connector methods.

      This is possible to simulate when multiple workitems are approved in one GUI action. All workitems e.g. deletes some value from the same role attribute. There must be other circumstance met, for this case to be practical, the read operation must take certain time, e.g. 500ms. This is why we dont see such problem much often on e.g. LDAP resource, which has generally fast reads.

      I wonder, why mp must even read the actual shadow state right before the update and then calculate replace list (it is in fact replace list, eventhought distributed in ADD + DELETE lists when mp happens to read old data). The primary delta is relative (e.g. delete assignment), the connector is relative (supports UpdateDeltaOp), the resource itself is relative as well.

      I know you have already investigated the area and posses deep knowledge, anyway possible (naive) solutions from me:

      • Ensure (somehow) that assignments from UserType and data from the resource are read in the VERY same time.
      • Introduce some liteway form of locking... mp wiki knows it all
      • Do not reconcile the object when workitem/async operation finishes. Just executes relative update.




            • Assignee:
              martin.lizner Martin Lizner
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: