Since the container cannot make any assumption on how long asynchronous tasks may run, usage of scopes is limited. Request-scoped or session-scoped beans that were available as the asynchronous task started are not guaranteed to be active during the whole execution; the request and session may have ended a long time ago. Threads that are running asynchronous tasks, for example, provided by a managed executor service or asynchronous events, can therefore not access the request-scoped or session-scoped bean instances that were active during the originating invocation. This also includes accessing references to injected instances, for example, in lambda methods that are part of the originating synchronous execution.

This has to be taken into account when modeling asynchronous tasks. All invocation-specific information needs to be provided at task start time. An asynchronous task can, however, have its own instances of scoped beans.