...
So, out of the box, the IdP software requires that flows involving views start and finish on the same node, the most common example being a login that requires a form prompt or redirect. This is similar to the way V2 worked, in that requests included a "login context" object that maintained state, but this state is now handled by SWF and is bound to the container session. That is a change, in that V2 did not rely on the container session at any point.
While some containers do have the capability to serialize session state across restarts or replicate sessions between nodes, and Spring Web Flow is able to leverage that mechanism, the IdP does not support that because the objects it stores in the session are not required to be "serializable" in the formal Java sense of that term. This greatly simplifies the development of the software, but makes clustering harder.
...
The former two are configured automatically after installation and are both used for various purposes by default. The latter two require special configuration (and obviously additional software with its own impact on clustering) to use.Notably, Terracotta, the replication solution supported by V2, is not supported; object replication solutions in general are not usable going forward.
Exceptional State
Excluding user credentials and user attribute data more generally, there is one exceptional case of data that may be managed by the IdP but is not managed by the unified StorageService API discussed above.
...