More on ORA-08177: can't serialize access for this transaction

[Cantor, Scott]

On 9/13/17, 9:25 PM, "users on behalf of Lionel Samuel" <users-bounces at shibboleth.net on behalf of lionel.samuel01 at gmail.com> wrote:

> If I understood correctly -- with current setup below -- you are recommending to uncomment 1st line below --- and comment out
> 2nd line?

I'm not recommending anything unless you understand in full detail everything you did before, are doing now, and would be doing if you changed it. This has profound and far reaching implications and is an inrrevocable decision to supply identifiers to other systems. That's true no matter how you do it. This shouldn't even be supported to begin with unless you absolutely have to do it. Pairwise identity is a very complex and very limited approach that is best avoided in most cases. I've run a SAML IdP for 13 years and I'm about to deploy it next week, over a great deal of personal concern and I'm fairly sure it won't end well.

To answer your question,

"idp.persistentId.generator" controls the name of the bean that ultimately produces the values. It's the key setting that switches between non-stored and stored.

"idp.persistentId.computed" is a setting that allows the database-backed generator to produce the initial generation of values using the same hashing that the other generator would use if there weren't a database. If you started with it commented out, you cannot have done this, and so you have produced random values stored in the database that are NOT compatible with the hash-based approach and you would break any application that was already depending on them.

-- Scott