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

[Lionel Samuel]

Not the real production salt.,....in case anyone wondering

On Wed, Sep 13, 2017 at 6:59 PM, Lionel Samuel <lionel.samuel01 at gmail.com>
wrote:

> 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.ComputedPersistent
> IdGenerator"?
>
> #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/5539621b/attachment-0001.html>