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

[Lionel Samuel]

There is no service leveraging the stored Persistent IDs to date --- so we
can sacrifice this if still having the Oracle issues on ORA-08177

Thank you for your help ---- one more qualification, if I needed to quickly
switch off database storage of Persistent ID --- the below is the
configuration? Second line,idp.persistentId.generator, changed from
"shibboleth.StoredPersistentIdGenerator" to "shibboleth.
ComputedPersistentIdGenerator"?

#idp.persistentId.computed = shibboleth.ComputedPersistentIdGenerator
idp.persistentId.generator = shibboleth.ComputedPersistentIdGenerator
idp.persistentId.dataSource = OracleDataSource
idp.persistentId.sourceAttribute = ubcEduCwlPuid
idp.persistentId.salt = wKpKzJQu88MOedKaV2KZH3SetUmsQkZZtjDzwVSRcVrBRWi7r+

On Wed, Sep 13, 2017 at 6:39 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> 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
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170913/e9b2e86f/attachment.html>