Error obtaining persistent identifier (ORA-08177: can't serialize access for this transaction)

[Chris Reeves]

Thanks for your replies Scott, I'll take a look at this tomorrow.

--chris

On Wed 07 Sep 2016 at 19:19:26 +0100, Cantor, Scott wrote:
> On 9/7/16, 1:48 PM, Chris Reeves wrote:
> >
> > I can reproduce this by using the browser's 'back' button, or hitting the
> > login page directly (such as a user would if they had 'bookmarked' the
> > login page). The error-messages.properties maps this error to the 'stale'
> > error message, so my feeling is that this isn't an error to worry about -
> > but it would be great if someone could confirm.
> 
> It's caused by the back button or bookmarks or cookie errors or deliberate
> replays or stale sessions that have timed out in the middle of a flow or
> about 60 other things.
>     
> > Caused by: java.io.IOException: java.sql.SQLException: ORA-08177: can't
> > serialize access for this transaction
> 
> Is that error code in your "retry" list? Other than forcing retries, there's
> nothing we can do to make transactions work, and that's the only allowance
> we can make. You can set any retryable errors you need to. Should be covered
> in the documentation, but...
> 
> > We've configured a StoredId data connector in attribute-resolver.xml (we
> > also need the StoredId for eduPersonTargetedID)
> 
> I don't know if we have fully implemented the range of needed options in the
> resolver version, as that's deprecated (and it's the one "really deprecated"
> thing we have). I think some of the options were added but buggy, but I
> don't remember which ones. If you can't implement the retryable error list
> there, there's really nothing to be done about it but not using Oracle.
> 
> > There's no funky transaction isolation configured on the connector - we're
> > just taking whatever the defaults are.
> 
> That's the problem, Oracle's portable SQL defaults violate the spec for
> locking assumptions (and increasingly it appears every database may be in
> that category).
> 
> The other options around this (e.g. customizing the SQL to use "select for
> update") only work with the NameID Generation component, not the deprecated
> connector.
> 
> > We only have one active server at a time (the other is a hot standby which
> > our load balancer will fail over to if necessary) so there shouldn't be
> > any conflict between the two servers. I should also note that this is not
> > something we saw on v2.
> 
> V2's database code there didn't work across a cluster (which is probably why
> you didn't notice, you only had one hot node).