<div dir="ltr"><div><div>Thanks Scott!<br><br></div>If I understood  correctly - it will be better to go with <span class="im">JPAStorage - this will take care of both the 'Consent'  and eduPersonTargettedId?<br><br></span></div><span class="im"></span></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 9, 2016 at 11:58 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> - Attribute Release Consent Form - if a user agrees to attributes release for<br>
> an application - can this be store indefinitely (i.e. user is not prompted again -<br>
> even if session expired)?<br>
<br>
</span>In memcache? Not unless you never restart it I guess. Memcache is not a persistence mechanism, it's just pretending to be one for long enough to handle session-oriented data, and our API doesn't distinguish those cases so that the code doesn't have to.<br>
<span class=""><br>
> - eduPersonTargettedId - in v3.2.1, there is an option now to store values in<br>
> database (a big help)?<br>
<br>
</span>There has always (almost anyway) been such an option.<br>
<span class=""><br>
> If above are stored in the database - would we be better off with JPAStorage<br>
> (instead of memcache)?<br>
<br>
</span>Pairwise IDs have to be much more robustly stored than consent records, so I would say if you manage to do one, you may as well do the other. The problem is getting any of it to work without compromising HA.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<br>
<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</font></span></blockquote></div><br></div>