Share all details related to your problem, including any error messages you may have received.
Hello,
Leaver event workflow de-provisioning has been implemented for various applications as follows.
App1 and app2 - Disable operation.
App3 and App4 - Delete operation.
App5 and App6 - Disable and remove entitlements.
Whenever the identity has app3 or App4 application accounts, those workflow case is failing with below error and this halting to rest workflow process execution.
An unexpected error occurred: A different object with the same identifier value was already associated with the session : [sailpoint.object.Link#0s54***************] - Id referring to app3 or app4 link Id and we can
We are compiling the plan with below arguments.
Set to true to enable optimistic provisioning. This will cause changes to the entitlements compiled from role assignments to be applied immediately to the identity cube rather than waiting for the next refresh/reaggregation after the provisioning system completes the request.
also check if you using context.decache() on the link object somewhere during the processing , which might generate these errors " A different object with the same identifier value was already associated with the session : [sailpoint.object.Link#0s54*"
IncrementalObjectIterator linkIter = new IncrementalObjectIterator(context, Link.class, queryOptionsAccount);
String isDisabled = "";
while (linkIter.hasNext()) {
Link linkVal = linkIter.next();
isDisabled = Boolean.toString(linkVal.isDisabled());
break;
}
Util.flushIterator(linkIter);
maybe we can consider decache the Link object, as we also load the Links again in the following method, maybe the Link there is already loaded in the above code?
List logicalAppLinks = identityService.getLinks(identity,logicalAppObject);
List adLinks = identityService.getLinks(identity,pAppObject);
In addition, just wondering why we would like to use IncrementalObjectIterator to retrieve the Link, why not just use below method:
Link link = IdentityService.getLink(Identity identity, Application application, java.lang.String instance, java.lang.String nativeIdentity);
boolean isDisabled = link.isDisabled();
context.decache(link);
Hi and Hello,
The error you’re encountering in your SailPoint IdentityIQ workflow, related to the message “A different object with the same identifier value was already associated with the session,” is often caused by Hibernate session conflicts. This occurs when there are attempts to use an entity that was already loaded in a different context or session within the same transaction, particularly in batch or complex operations like those in a provisioning plan.
Session Management and Object Identity:
Ensure that any object (like Link or Identity) retrieved from the database is managed properly. If an object is fetched and then modified, make sure that any changes are flushed and the session is cleared if necessary to avoid conflicts. This is crucial when working with batch operations or loops where the same object may be processed multiple times.
Decaching Strategy:
It looks like you’re already attempting to decache objects (context.decache(logicalAppObject)), which is good practice in long-running operations involving multiple transactions. However, make sure that this is done judiciously to avoid unintended side effects. Decaching should be done just before the object’s updated version is required or after significant changes have been committed to ensure the session does not hold stale objects.
Optimistic Locking:
Your setup mentions optimistic provisioning. Ensure that the entities involved in your transactions are configured to support optimistic locking if applicable. This can prevent conflicts by ensuring that the last write wins, and it also provides better error handling capabilities when concurrent modifications occur.