IdP3 Clustering...

[Andrew Morgan]

On Thu, 1 Dec 2016, Cantor, Scott wrote:

>> We have done persistent id this way since the beginning of time.  As long as
>> each host computes the id the same way all the local DBs stay synchronized.
>> And it's resilient.
>
> Computed, yes. You can certainly store the results of a computation and 
> not worry about it, or store seeds for the computation so if you have to 
> change them you just manually sync that data. That isn't what our 
> StoredId code does, however, and since everybody pretty much just moved 
> to Computed alone or just didn't bother to support the feature, there's 
> not been a push to go back and redo all that so far.

Now this is an interesting idea...  I'm not sure if it's what Jim was 
saying though.

For the purpose of releasing a persistent NameID, a master-slave or 
"eventually consistent" database could work fine.  If the persistent 
NameID is generated on the fly and stored in the database, then it isn't 
crucial that the replication happen in real-time.  If node A generates a 
NameID but Node B doesn't see it right away and generates the same NameID, 
that's okay.

If an admin wants to revoke or change the stored NameID value, it probably 
doesn't need to update in real-time on all nodes.

I still wouldn't use a database for session storage.

 	Andy