Server-side JPAStorageService using an eventually consistent database

[Rod Widdowson]

> Before pursuing this further, I would be happy if you could share
> experience (if any) or general estimates on this.


You will probably need to wait until after US thanksgiving for the definitive answer, but if I had to guess the hit on A' would require another login (obviously) and that would (probably) cause the 'session' (used in the loosest sense) on A to expire, meaning that an inopportune hit back on A would cause another login.  

But that is an wild guess, I haven't worked closely on that code...

Sent from my iThing

> On 24 Nov 2016, at 07:15, Martin Haase <Martin.Haase at DAASI.de> wrote:
> 
> Dear list,
> 
> we are about to investigate what happens if the current IdP's
> JPAStorageService implementation will be connected to an eventually
> consistent database cluster. This would mean
> 
>  * the IdP writes its storage record to one database node A,
>  * some subsequent write or read event will hit another node A'
>  * there is no guarantee that the storage record is already replicated
>    from A to A'
>  * the only guarantee is that information converges from A to A' at
>    /some/ possibly later point in time
>  * there might arise conflicts caused by replication mechanism (i.e.
>    which write event "wins"?)
> 
> Before pursuing this further, I would be happy if you could share
> experience (if any) or general estimates on this.
> 
> Thanks
> 
> Martin
> 
> 
> -- 
> Dr. Martin Haase, Solutions Engineer
> 
> DAASI International GmbH        
> Europaplatz 3                   
> D-72072 Tübingen                
> Germany                    
> 
> phone: +49 7071 407109-0
> fax:   +49 7071 407109-9  
> email: martin.haase at daasi.de
> web:   www.daasi.de
> 
> Sitz der Gesellschaft: Tübingen
> Registergericht: Amtsgericht Stuttgart, HRB 382175
> Geschäftsleitung: Peter Gietz
> 
> 
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161124/2bff56f3/attachment.html>