No flow execution could be found with key 'e1s1'
Y Levine
ylevine20 at gmail.com
Wed Aug 23 21:38:02 EDT 2017
Hello Scott:
Thank you for your reply and feedback.
We require database storage to store the attribute release consent (session
not necessary)....and also store the persistent ID.
Legal obligation to store for the attribute release intercept records +
support reasons to store the persistent ID (in shibpid)
Is it possible to remove DB storage of session .... but maintain the
storage of the attribute release intercept and shibpid (persistentID)?
We used the Step 5 instructions at
https://www.switch.ch/aai/guides/idp/installation/ (but with Oracle instead
of PostgressSQL)
On Wed, Aug 23, 2017 at 6:17 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 8/23/17, 9:05 PM, "users on behalf of Y Levine" <
> users-bounces at shibboleth.net on behalf of ylevine20 at gmail.com> wrote:
>
> > Are they linked? What could be the root cause?
>
> They have nothing to do with each other. The root cause is that Oracle
> stopped supporting transactions and locking properly many years ago, as
> have many other databases, because of a misguided attempt to favor
> performance over correctness. The code assumes transactions and locking
> work because that's what the SQL standard says should happen. When the
> database doesn't honor that, the code breaks and retries a set amount and
> eventually gives up and fails whatever it was trying to do.
>
> > We are using Stoiragerecords --- on an Oracle DB
>
> I would reconsider using a database, and absolutely wouldn't use one for
> the IdP's sessions. I wouldn't use one for anything if it was in any way
> avoidable.
>
> -- 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/20170823/d879e59e/attachment.html>
More information about the users
mailing list