Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) : sailpoint.object.IdentityEntitlement

[akhil_chidurala (chidurala Akhil)]

We are getting refresh error during refresh identity cube the error is below
Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) : [sailpoint.object.IdentityEntitlement#0afff57f89121a4681895b34b49c5bab]

we have 10 workflows and multiple rules which use context.commitTransaction() What is best solution to resolve the error because of error the users are also not getting terminated.

[drosenbauer (Devin Rosenbauer)]

A stack trace would be very helpful here. My bet is that it comes from the API class PlanApplier.

This kind of thing happens when:

1. The IdentityEntitlement object is saved, and that save fails. This would throw an exception, but you or an API might be catching and logging the exception.

2. The IdentityEntitlement object is still added to the Identity object, even though the save had failed.

3. You attempt to save the Identity object.

IIQ then attempts to save all of the associations from the parent Identity object to the child IdentityEntitlement objects, which fails because one of those IdentityEntitlement objects was never saved in the first place.

[akhil_chidurala (chidurala Akhil)]

Hi @drosenbauer ,

Could you provide me some brief to resolve the error.
I had checked through compass but didn’t able to find anything related to this error
Sailpoint support suggested to modify the workflows.
What exactly should be modifed in the workflow I am not sure.
because of the error in the refresh the terminations are not getting triggered regularly.

[Remold (Remold Krol)]

There are several issues when using commitTransaction in workflows. The biggest issue is that it will commit the complete transaction and not only the object you want to save to the database. Where the complete transaction is everything in the workflow (the workflow state).

During the refresh a workflow is started it will basically start a transaction. This transaction will be committed when the workflow finishes. If there is an error in the workflow the transaction can be rolled back (just like SQL transactions, with a similar explanation on https://www.sqlshack.com/transactions-in-sql-server-for-beginners/).

When you include a commitTransaction in a workflow, this means the workflow transaction is committed in the middle of the workflow, where a rollback to the beginning of the workflow is not possible anymore.

Also the commitTransaction in a workflow might also result in the well known ‘failed to lazily initialize a collection’-error as it will store the workflow state in the database which include the storage of all objects and some objects (like Identity) can not be stored in a workflow state.

So best practice is not to use commitTransaction in workflows.

There are some options which might solve your issue (this need some testing from your side):

• Locking the object before changing and save it without commitTransaction (See Locking a SailPoint object - Compass and skip the context.comitTransaction and context.decache
• Start a new transaction like:

  context.startTransaction();
  .... make changes ...
  context.saveObject(identity);
  context.commitTransaction();
  

I hope this helps

– Remold