Interface ProcessSession


public interface ProcessSession
A process session encompasses all the behaviors a processor can perform to obtain, clone, read, modify remove FlowFiles in an atomic unit. A process session is always tied to a single Processor at any one time and ensures no FlowFile can ever be accessed by any more than one processor at a given time. The session also ensures that all FlowFiles are always accounted for. The creator of a process session is always required to manage the session.

A session is not considered thread safe. The session supports a unit of work that is either committed or rolled back.

As noted on specific methods and for specific exceptions automated rollback will occur to ensure consistency of the repository. However, several situations can result in exceptions yet not cause automated rollback. In these cases the consistency of the repository will be retained but callers will be able to indicate whether it should result in rollback or continue on toward a commit.

A process session has two types of 'terminal' methods that will result in the session being in a 'fresh' state, containing no knowledge or any FlowFile, as if the session were newly created. After one of these methods is called, the instance may be used again. The terminal methods for a process session are commitAsync() and rollback() (and their overloads).

Additionally, the migrate(ProcessSession, Collection) method transfers all knowledge of the provided FlowFiles to the other process session, as if the FlowFiles never existed in this process session. Note, however, that even if all FlowFiles are migrated via the migrate(ProcessSession, Collection) method, the session is not necessarily entirely cleared, as it still may have knowledge of counter adjustments or state changes, e.g. see methods adjustCounter(String, long, boolean) or setState(Map, Scope). A commit or rollback will clear these changes as well.