ODBC Session store for Shibboleth SP, error with NameID insert
Michael A Grady
mgrady at unicon.net
Thu May 21 19:55:07 EDT 2015
On May 21, 2015, at 2:29 PM, Cantor, Scott <cantor.2 at OSU.EDU> wrote:
> On 5/21/15, 3:01 PM, "Michael A Grady" <mgrady at unicon.net> wrote:
>
>> The SP determines it needs to insert a new session, and it succeeds in starting to store a new session. But when it tires to find an existing entry for texts/NameID with an expires > datetime, ti doesn't find any, so goes to INSERT a new one. That generates the error, because the key for such an entry already exists (key is combo of context and id, in this case NameID and Someone at email.com.) It appears to generally repeat the attempt to insert for 11 times, before it gives up, and considers the session created without that.
>>
>> I've never looked carefully at the SP's session storage. Just wondering if an error like this would be indicative of any kind of config error for the ODBC setup or not. However, most of the time, that INSERT is working just fine.
>
> When you actually verbalize what it's doing, it makes me suspect there's a bug because of the gap of potentially having an expired record in there blocking the insert, so I would have to take a look at what it's actually doing. Please file a bug.
Will do. I figured it might be a condition that shouldn't arise if session management/cookies/everything else had worked as expected. Or that it could be a bug to do the search on a set of conditions that go beyond the key fields, and then assume one could insert a new record when that search doesn't return anything.
>
> If it's not actually deadlocking, that's not likely to be a database problem with a race condition and a lack of appropriate locking.
>
> Unless logout is used, there's also no reason to let it maintain that secondary index.
>
--
Michael A. Grady
IAM Architect, Unicon, Inc.
More information about the users
mailing list