Page History

...

On later requests, the value for such persistent fields is reloaded from storage.

Persistence Strategies

The value for each field is the strategy used to store the field between requests.

Session Strategy

The session strategy stores field changes into the session; the session is created as necessary.

...

Session strategy is the default strategy used unless otherwise overridden.

Flash Strategy

The flash strategy stores information in the session as well, just for not very long. Values are stored into the session, but then deleted from the session as they are first used to restore a page's state.

The flash is typically used to store temporary messages that should only be displayed to the user once.

Client Strategy

The field is persisted onto the client; you will see an additional query parameter in each URL (or an extra hidden field in each form).

...

Use client persistence with care, and store a minimal amount of data. Try to store the identity (that is, primary key) of an object, rather than the object itself.

Persistence Strategy Inheritance

By default the value for the Persist annotation is the empty string. When this is true, then the actual strategy to be used is determined by a search up the component hierarchy.

...

In any case, if no component provides the meta data, then the ultimate default, "session", is used.

Default Values

Fields marked with @Persist may not have default values (whether set inline, or inside a constructor).

Clearing Persistent Fields

If you reach a point where you know that all data for a page can be discarded, you can do exactly that.

The method discardPersistentFieldChanges() of ComponentResources will discard all persistent fields for the page, regardless of which strategy is used to store the property. This will not affect the page in memory, but takes effect for subsequent requests.

Clustering Issues

The Servlet API was designed with the intention that there would be only a modest amount of server-side state, and that the stored values would be individual numbers and strings, and thus, immutable.

...

Tapestry has solutions to this.

Immutable Objects

Tapestry knows that Java's String, Number and Boolean classes are immutable. Immutable objects do not require a re-store into the session.

You can mark your own session objects as immutable using the ImmutableSessionPersistedObject annotation.

OptimizedSessionPersistedObject

The OptimizedSessionPersistedObject interface allows an object to control this behavior. An object with this interface can track when its mutable state changes. Typically, you should extend from the BaseOptimizedSessionPersistedObject base class.

SessionPersistedObjectAnalyzer

The SessionPersistedObjectAnalyzer service is ultimately responsible for determining whether a session persisted object is dirty or not (dirty meaning in need of a restore into the session). This is an extensible service where new strategies, for new classes, can be introduced.