StoredID data connector: what happens when the database goes down?

[Wessel, Keith]

Honestly, all I was referring to was that the documentation on the wiki for the stored ID data connector makes no mention of the failover element. I re-read my note just now and was very misleading on that. My apologies.

If this is supported, it gives me a few more options: falling back to computed ID, probably unwise as the eptid could change; falling back to a static connector that returns an empty element, possibly a best case in the event that the stored ID connector is unavailable; or do nothing and let everything fail, glad we're getting away from that model in V3.

I'll set something up with a failover element and, if it doesn't work, report back. If it does work, I can see about adding to that wiki page so other lonely IDP operators (to quote Max) like myself don't re-ask this question.

Thanks, and sorry for my misleading note.
Keith


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Friday, June 13, 2014 8:55 AM
To: Shib Users
Subject: Re: StoredID data connector: what happens when the database goes down?

On 6/12/14, 1:10 PM, "Wessel, Keith" <kwessel at illinois.edu> wrote:

>Sorry, sure enough, you were clearer on that. I didn't read carefully
>enough.
>
>Problem is the storedid dataconnector doesn't seem to include support for
>the failover dataconnector element. I can, if not using a container-based
>database configuration, define a pool of Oracle database servers, but
>that only helps if my database architecture is set up as such.
>
>So, is something missing from the docs here? Or is there no alternative
>if the database is unavailable and, as you said, no attributes will be
>returned to the SP?

IIRC, all data connectors can have failovers, but it's not impossible this
is broken or limited in some way for those connectors. Could you verify
that one way or the other, and if needed, file a RFE against V3 for this.
Won't be immediate, but I'll make sure the new ones properly handle
failure options. I don't believe in the "one failure fails everything"
mode that Chad tended to favor, and I'd rather not have to define
failovers just for that flag.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net