IdPv3: race condition causes two persistentId to be generated

[Cantor, Scott]

The fix for this bug [1] is complete at this point and I have new documentation written that addresses the changes to configuring the Stored persistentID mechanism, and the implications of upgrading to 3.2. [2] Once the release is done, we'll replace the existing documentation with the new page, and highlight this in the release notes.

I'd appreciate review by the OP and anybody else using the database-backed mechanism to check for clarity or any concerns. Testing a 3.2 snapshot would be even better.

I believe the documentation now is explicit that you must have a primary key on the table for this to be safe to use, and it's not possible to use loosely replicated databases either (that was never the intention and would never be workable for this use case without problems).

The intention of my fix is that you should not see any breakage on an upgrade, but actually getting the fix to take hold will usually involve a table change or reload of the data to get a constraint added.

-- Scott

[1] https://issues.shibboleth.net/jira/browse/IDP-829
[2] https://wiki.shibboleth.net/confluence/x/ZYFKAQ