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

[Cantor, Scott]

On 9/7/16, 1:48 PM, "users on behalf of Chris Reeves" <users-bounces at shibboleth.net on behalf of chris.reeves at york.ac.uk> 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).

-- Scott