[CAUSEWAY-2301] Docs for new InteractionScope

• Type: Documentation
• Status: Reopened
• Priority: Major
• Resolution: Unresolved
• Fix Version/s: 2.1.0
• Component/s: Docs & Website
• Assignee: Unassigned
• Reporter: Andi Huber
• Created: 04/Mar/20 08:05
• Updated: 03/May/22 06:26

Description

We allow IsisInteractions to be nested. The @IsisInteractionScope is always bound to the top-level IsisInteraction of the current thread's session stack. (first stack element, aka bottom of stack)

Isis (not Spring) is aware, when any IsisInteractionScope ends. So at the end of each IsisInteractionScope, we call the destruction runnables on the IsisInteractionScope-d beans that belong to the current thread, then clear the IsisInteraction stack (of the current thread). (edited)

The IsisInteractionScope-d beans are managed by Spring, that is Spring creates them and registers their destruction runnables.

Requires Provider idiom: we fail early if one tries to inject an IsisInteractionScope-d bean directly. The thrown exception gives a hint, how to fix it. (Use the Provider<> idiom instead)

Issue Links

• is related to: CAUSEWAY-2296 @RequestScoped isn't honoured
• is related to: CAUSEWAY-2441 Auditing/Publishing: dispatch calls happen before enlist calls
• is related to: CAUSEWAY-2320 Rename IsisSessionScope -> IsisInteractionScope
• is related to: CAUSEWAY-2323 Allow for IsisInteractions to store User Data (InteractionScoped)