When I have x number of users with the same seed criteria (say, 10 x John Doe) for username generation, and there’s a lookup / collision check (and re-generation loop) in the attribute generator rule, but they still end up colliding due to the race condition of in-flight, non-committed account creations.
How’s everyone addressing this? Are you going with the “Let one win, then retry the rest” approach, or have you been able to gracefully handle that with some kind of a locking / mutex mechanism in the ISC world even when the guidelines seem to imply rules should be non-blocking (as the rule can’t / shouldn’t wait).
Hi @David_Norris Are you treating this as an initial data load issue or a BAU issue? By keeping uniqueness checking on the target source rather than identity profiles and because most use cases aren’t bulk creating accounts this isn’t a common occurrence.
It’s BAU. High seasonal joiner scenario. Yeah, I understand it’s not a ‘common’ scenario. This is more of a curiosity question (as we’re moving forward with the “Let one win, the rest will retry” approach). Assuming the requirement (seed criteria) cannot be changed, how would this be addressed in ISC?
HR intervention where they input duplicate names over a period of days.
However, I was working on a project where the seasonal input was 50,000+ very september, and I never ran into race conditions. Username generation came from AD account creation and was the sAMAccount name
It’s a potentiality type situation for us. i.e. Awareness of the fact that it ‘can’ happen…and how it needs to be handled. There are ‘workarounds’ for this based on reality (e.g. Aggregate more frequently so that two "John Doe"s don’t show up at the same time).
This is part of our solutioning, knowing the limitations, and planning for situations when the scenario ever does occurs…and artificially create that test case to test against. Minimize surprises at runtime / BAU.
(i.e. Build something that works, but more importantly, build something that still works when it’s failing)