Status of session code

[Cantor, Scott]

On 9/26/13 4:27 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>I thought I understood this, but now I have doubts so let me try for a
>concrete example:
>
>It means that thinks like TOU or Consent will not be able to see the
>[same]
>session object as the one used in Authentication, they will only see what
>has been deserialized from the storage layer?

Unlikely, because they'll probably see the same SessionContext created
during the earlier part of the web flow.

I'm referring to separate requests running in different tabs or frames
that are running in parallel sending the same cookie(s) to the IdP. They
all refer to one session, but I'm not planning to implement a
shared/synchronized object for them all to manipulate together and keep
coherent with the stored copy. Each one would see some state of the
session recovered from backing store but then they'd be making independent
updates to their own copy until it eventually gets saved back.

>But - AIUI they will see that a change has happened when the store
>conditional fails.  In that case they are just doing idempotent changes
>then
>they could rerun that stage - if it matters?

The write back will see that a change took place, but how intelligent the
merging of changes is depends on the use case. In many cases I think "last
one wins" will be good enough, but I haven't gotten that far.

-- Scott