Status of session code

[Rod Widdowson]

> I do have one design choice to highlight, which is that I'm favoring an
> implementation that doesn't try and share a user's session object across
> transactions/requests in the IdP, even within a single node. It's
> basically handing out the IdPSession object on a per-request basis and the
> only shared state across requests is in the storage layer (where I have
> versioning support). 

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?

> A consequence is that technically you can have
> simultaneous requests active on the same session that will not necessarily
> see each other's changes while running

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?

/Rod