Server-side JPAStorageService using an eventually consistent database

[Martin Haase]

Hi Scott,

thanks for this. So...

Am 25.11.2016 um 18:05 schrieb Cantor, Scott:
> On 11/24/16, 2:15 AM, "users on behalf of Martin Haase" <users-bounces at shibboleth.net on behalf of Martin.Haase at DAASI.de> wrote:
>
>> we are about to investigate what happens if the current IdP's
>>    JPAStorageService implementation will be connected to an eventually
>>    consistent database cluster.
> In general, it's not advisable, but it depends on the specifics of each storage client. In some respects the client storage service now is "kind of" eventually consistent. There are race conditions possible and the risk of records being lost in some cases but because it's used for the session cache primarily, the main outcome is just more frequent login, or possibly some risk of logout failure (taking logout from "impossible" to "slightly more impossible").
>
> There are use cases involving server side storage where those risks are much greater and involve loss of replay cache integrity or even more importantly failures to handle artifacts or CAS tickets leading to login failure at services.
...this looks better than I was hoping.
>> Before pursuing this further, I would be happy if you could share
>>    experience (if any) or general estimates on this.
> I think there are much better choices, personally, in the majority of cases.
What do you have in mind here?

Best regards,
Martin
>
> -- Scott
>
>

-- 
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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2247 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://shibboleth.net/pipermail/users/attachments/20161129/c9c80ef4/attachment.p7s>