ORA-08177: can't serialize access for this transaction
Lionel Samuel
lionel.samuel01 at gmail.com
Mon Sep 11 16:26:42 EDT 2017
Hi Rod:
Thanks --- very helpful.
Added queryTimeout & retryableErrors to our config --- will test and
monitor.
p:initialSize="5" p:maxTotal="100" p:maxIdle="25"
p:maxWaitMillis="2000" p:testOnBorrow="true"
p:testWhileIdle="true" p:testOnReturn="true"
p:timeBetweenEvictionRunsMillis="120000"
p:minEvictableIdleTimeMillis="60000" p:validationQuery="select 1 from
dual" p:validationQueryTimeout="4" p:queryTimeout="PT2S"
p:retryableErrors="#{{'08177'}}" />
On Mon, Sep 11, 2017 at 1:25 AM, Rod Widdowson <rdw at steadingsoftware.com>
wrote:
> > Quite new to Shibboleth and I can't say I completely understand the
> explanation in thread --- is it due to a race
> > condition, what steps can alleviate it?
>
> The SQL standard defines rules for how locking around transactions should
> work. In their race to prove how fast they are many vendors completely
> ignore these rules ("performance enhancement through incorrect operation").
>
> In order to deal with their shoddy coding, applications have to take
> remedial action and "if it fails, try again" ("Oh look, that million dollar
> transfer I made probably didn't work, maybe I should try again").
>
> Shibboleth has code to allow you to do this, but you have to enable it. -
> if you look here [1] you will see examples:
>
> > The most common settings to override are the queryTimeout, and to
> provide a list of retryableErrors that
> > are reported when a database improperly fails to prevent a duplicate
> insert.
>
> [1] https://wiki.shibboleth.net/confluence/display/IDP30/
> PersistentNameIDGenerationConfiguration
>
> --
> 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/20170911/a8036b18/attachment.html>
More information about the users
mailing list