# Same request executes multiple times on multiple VMs **URL:** \ **Category:** IIQ Discussion and Questions\ **Tags:** request, workflows, identityiq\ **Created:** [January 14, 2026, 6:43pm UTC](https://developer.sailpoint.com/discuss/t/same-request-executes-multiple-times-on-multiple-vms/193373 "2026-01-14T18:43:20Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![opalyvoda](https://avatars.discourse-cdn.com/v4/letter/o/439d5e/32.png) [@opalyvoda](https://developer.sailpoint.com/discuss/u/opalyvoda)\ **Post date:** [January 14, 2026, 6:43pm UTC](https://developer.sailpoint.com/discuss/t/same-request-executes-multiple-times-on-multiple-vms/193373/1 "2026-01-14T18:43:20Z")
## Which IIQ version are you inquiring about? _8.4 p2_ ## # Context We use workflow “Scheduled Assignment” to remove access, which is IT role, from Identity at defined Sun Set Date and Time. Internally this is handled by request scheduled to execute mentioned workflow at Sun Set Date and Time. We enabled saving Task Results by removing _resultExpiration=“-1”_ XML attribute from Workflow element. So we see task results. # Issue We see request sometimes (once or twice a day) executed multiple times on multiple VMs. We have 4 VMs executing requests. Most of the errors happen due to 2 executions, however - sometimes we see 3 executions at the same time. Executions happen very close in time (within 2 seconds) of each other. On less loaded Staging environment this issue does not show. Problem is that earliest execution does remove role, while everyone after fails because role is not on the Identity. “Scheduled Assignment” workflow has number of steps between _Compile Project_ and _Provision_. We think it is concurrency issue. # Questions Did anyone encountered similar situation? Is there some configuration, except using only one VM for request execution, to help with this situation? Thank you ---
**Author:** ![opalyvoda](https://avatars.discourse-cdn.com/v4/letter/o/439d5e/32.png) [@opalyvoda](https://developer.sailpoint.com/discuss/u/opalyvoda)\ **Post date:** [January 15, 2026, 2:50pm UTC](https://developer.sailpoint.com/discuss/t/same-request-executes-multiple-times-on-multiple-vms/193373/2 "2026-01-15T14:50:04Z")
Update is that Staging environment, with 3 WMs also executes same request on each VM. This was proved by enabling logs: `logger.sailpointRequestWorkflowRequestExecutor.name=sailpoint.request.WorkflowRequestExecutor logger.sailpointRequestWorkflowRequestExecutor.level=all logger.sailpointRequestRequestHandler.name=sailpoint.request.RequestHandler logger.sailpointRequestRequestHandler.level=debug logger.sailpointRequestRequestProcessor.name=sailpoint.request.RequestProcessor logger.sailpointRequestRequestProcessor.level=debug logger.sailpointRequestRequestService.name=sailpoint.request.RequestService logger.sailpointRequestRequestService.level=debug` ---
**Author:** ![paul\_hilchey](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/paul_hilchey/32/24080_2.png) [@paul\_hilchey](https://developer.sailpoint.com/discuss/u/paul_hilchey)\ **Post date:** [January 16, 2026, 6:55am UTC](https://developer.sailpoint.com/discuss/t/same-request-executes-multiple-times-on-multiple-vms/193373/3 "2026-01-16T06:55:08Z")
Hi @opalyvoda what are you settings in iiq.properties for: - scheduler.quartzProperties.org.quartz.scheduler.instanceId - scheduler.quartzProperties.org.quartz.jobStore.isClustered I believe the default is to not do any locking in the database, which can result in jobs being launched on more than one application server. ---
**Author:** ![opalyvoda](https://avatars.discourse-cdn.com/v4/letter/o/439d5e/32.png) [@opalyvoda](https://developer.sailpoint.com/discuss/u/opalyvoda)\ **Post date:** [January 16, 2026, 2:57pm UTC](https://developer.sailpoint.com/discuss/t/same-request-executes-multiple-times-on-multiple-vms/193373/4 "2026-01-16T14:57:07Z")
Hello Paul, Thank you for response. We do not have both: _scheduler.quartzProperties.org.quartz.scheduler.instanceId_ and _scheduler.quartzProperties.org.quartz.jobStore.isClustered_ in iiq.properties. I looked up Google AI for `"scheduler.quartzProperties" "quartz.jobStore.isClustered"` and it is a very good candidate not only for Request but also for anything quartz manages in IdentityIQ. Will test this, Regards ---
**Author:** ![paul\_hilchey](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/paul_hilchey/32/24080_2.png) [@paul\_hilchey](https://developer.sailpoint.com/discuss/u/paul_hilchey)\ **Post date:** [January 17, 2026, 10:15pm UTC](https://developer.sailpoint.com/discuss/t/same-request-executes-multiple-times-on-multiple-vms/193373/5 "2026-01-17T22:15:28Z")
Hi Oleh, We are using these settings with good results: - scheduler.quartzProperties.org.quartz.scheduler.instanceId=AUTO - scheduler.quartzProperties.org.quartz.jobStore.isClustered=true I’m puzzled why they are not the default settings. ---
**Author:** ![opalyvoda](https://avatars.discourse-cdn.com/v4/letter/o/439d5e/32.png) [@opalyvoda](https://developer.sailpoint.com/discuss/u/opalyvoda)\ **Post date:** [January 22, 2026, 4:22pm UTC](https://developer.sailpoint.com/discuss/t/same-request-executes-multiple-times-on-multiple-vms/193373/6 "2026-01-22T16:22:32Z")
More research showed that RequestProcessor class method `private void processRequest(SailPointContext context, ThreadPool pool, String id)` which looks like is the one, uses call `Request request = (Request)ObjectUtil.transactionLockById(context, Request.class, id);` Transaction lock seams to work only inside Hibernate Session, in other words - lock works within one VM. For lock to mutually exclude between multiple VMs - it has to be _persistent_ lock. This way it would go to DB and visible across VMs. In addition, as far as I understand, Request processing is not using Quartz. ---
**Author:** ![paul\_hilchey](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/paul_hilchey/32/24080_2.png) [@paul\_hilchey](https://developer.sailpoint.com/discuss/u/paul_hilchey)\ **Post date:** [January 29, 2026, 3:27am UTC](https://developer.sailpoint.com/discuss/t/same-request-executes-multiple-times-on-multiple-vms/193373/7 "2026-01-29T03:27:27Z")
Hi Oleh, I believe transaction locks are implemented as database locks, so they should work between application servers. Possibly there is something wrong with your hibernate settings? ---
**Author:** ![neel193](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/neel193/32/34038_2.png) [@neel193](https://developer.sailpoint.com/discuss/u/neel193)\ **Post date:** [February 6, 2026, 6:29pm UTC](https://developer.sailpoint.com/discuss/t/same-request-executes-multiple-times-on-multiple-vms/193373/8 "2026-02-06T18:29:04Z")
@opalyvoda Paul rightly said transactions lock should lock the object across all threads and servers and if they try to access, they simply need to wait. While you fix the concurrency issue, as a stopgap solution you might want to add a transition script in your “Scheduled Assignment” to check if the user still has the access or not, if not, then you transition to end, otherwise move forward with the next step. ---
**Author:** ![opalyvoda](https://avatars.discourse-cdn.com/v4/letter/o/439d5e/32.png) [@opalyvoda](https://developer.sailpoint.com/discuss/u/opalyvoda)\ **Post date:** [February 6, 2026, 8:15pm UTC](https://developer.sailpoint.com/discuss/t/same-request-executes-multiple-times-on-multiple-vms/193373/9 "2026-02-06T20:15:21Z")
Hello Neelmadhav, I agree with transaction going to DB. While analyzing logs from 3 VM on millisecond level I noticed requests being executed sequentially. I tried to simulate situation in our Staging today and this time there were no errors. In production I see duplicated and errored out executions, not many. Starting from Feb 1 2026 until now failure rate is 0.963% or 0.00963 requests failing out of all executed. I was thinking about Hibernate cache. It might be that cache is populated when requests start and each VM see role assigned to identity from cache. I’ll try to drop cache in Start step and see if this helps. Ideally when Plan gets compiled into Project IdentityIQ notices that role to be removed is not assigned anymore and does not include this role into project. Is this correct? I’m not actively working on this issue, so will respond with some delays. Thank you for following up, I’ll try adding condition and skip significant part of workflow if identity does not have role to be removed. ---
**Author:** ![r\_pragati](https://avatars.discourse-cdn.com/v4/letter/r/41988e/32.png) [@r\_pragati](https://developer.sailpoint.com/discuss/u/r_pragati)\ **Post date:** [February 7, 2026, 7:31pm UTC](https://developer.sailpoint.com/discuss/t/same-request-executes-multiple-times-on-multiple-vms/193373/10 "2026-02-07T19:31:15Z")
Do you see a “Request” object created in the debug page for the deprovisioning of role? if so, you can see which VM it will run on? you will also see if multiple requests are created. ---
**Author:** ![system](https://global.discourse-cdn.com/sailpoint/original/2X/f/f2136700ed5e3703e0b85e02f6be799dacca7735.png) [@system](https://developer.sailpoint.com/discuss/u/system)\ **Post date:** [April 8, 2026, 7:31pm UTC](https://developer.sailpoint.com/discuss/t/same-request-executes-multiple-times-on-multiple-vms/193373/11 "2026-04-08T19:31:45Z")
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.