Shibboleth Developers

["Scott Cantor" <>]

> I'm testing ODBC store on Oracle with a load of 250 new sessions per
> day, with two machines.

That's obviously not a load, it would qualify as trivial usage. My point
being I don't think this tells us a lot. If anything it says even no load
has some issues.

> Everything seems to work fine (I'm having some "replay detected of
> message ID", but I don't think they're critical), and this is very good
> since we need to use Shibboleth authentication on a lot of load balanced
> servers.

Replay usually just means the user got back button happy. IdPs SHOULD
prevent this. It frustrates me that more don't.

> The problem is that Oracle throws this error to the ODBC driver, and the
> application is supposed to retry the insertion.

That's sensible, but it's a problem unless I can generically identify the
condition across drivers...

Basically, I'm well aware that serialization means I should retry on
failure, but I didn't have the time to reproduce the condition and figure
out how to detect it.

> I think that possible solutions are hardcoding the check into
> createRow(), or changing the transaction isolation level for the storage
> to READ_COMMITTED.

READ_COMMITTED can be a problem for updates. Not all, but some, including
some I support. Without serializing, updates can stomp on each other,
because I have to read the record out, modify it, and then update it back.
If that happens without a lock around the three steps, you have a race
condition.

Now, in practice, does the SP currently use those code paths? I don't think
so, at least not with the delivered plugins. They would mainly come up if
the SP was caching tokens obtained later in the session, basically web
service use cases.

Basically, I'm ok with exposing a property to set the isolation level. But
I'm not ok with setting it to READ_COMMITTED (which is not ACID, it's the
second lowest iso level) for everybody. And I don't know what the
implications would be in all cases.

My preference is to do some research into detecting lock contention so I can
just retry the transaction.

-- Scott