Persistent Page Data

Most instance variables in Tapestry are automatically cleared at the end of each request. This is important, as it pertains to how Tapestry pages are shared, over time, by many users.

However, you often want to store some data on a single page, and have access to it in later requests to that same page, without having to store it in a database between requests. (To store values across multiple pages, see Session Storage.)

Making page data persist across requests to a single page is accomplished with the @Persist annotation. This annotation is applied to private instance fields of components:

  @Persist
  private int value;

Such annotated fields will retain their state between requests. Generally, speaking, this means that the value is stored into the session (but other approaches are possible).

Whenever you make a change to a persistent field, its value is saved. On later requests to the same page, the value for the field is restored.

Persistence Strategies

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

Session Strategy

A suitably long session attribute name is used; it incorporates the name of the page, the nested component id, and the name of the field.

  @Persist
  private int value;

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.

  @Persist(PersistenceConstants.FLASH)
  private int value;

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).

Client persistence is somewhat expensive. It can bloat the size of the rendered pages by adding hundreds of characters to each link. There is extra processing on each request to de-serialize the values encoded into the query parameter.

Client persistence does not scale very well; as more information is stored into the query parameter, its length can become problematic. In many cases, web browsers, firewalls or other servers may silently truncate the URL which will break the application.

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.

  @Persist(PersistenceConstants.CLIENT)
  private int value;

Hibernate Entity Strategy

Entity persistence is provided by the tapestry-hibernate module (which extends Tapestry with new features).

In Entity persistence, the field should store a Hibernate entity instance.

  @Persist(HibernatePersistenceConstants.ENTITY)
  private User user;

The value stored in the HttpSession is a token for the entity: its Java class name and primary key. When the field is restored in a later request, the entity is re-instantiated using that data.

What is not stored is any changes to the persistent entity that are not committed to the external datastore (the database).

Starting in Tapestry 5.4, it is possible to store a non-persistent entity (a transient entity). A transient entity is stored directly into the HttpSession, and should be Serializable if the application is clustered.

JPA Entity Strategy

The tapestry-jpa module uses a similar strategy. However, at the current time it can only store a persisted entity (one that has been saved to the database and has a primary key).

  @Persist(JpaPersistenceConstants.ENTITY)
  private Account account;

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.

For each component, the meta-data property tapestry.persistence-strategy is checked. This can be specified using the @Meta annotation.

If the value is non-blank, then that strategy is used. This allows a component to control the persistence strategy used inside any sub-components (that don't explicitly use a different strategy).

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.

  @Persist(HibernatePersistenceConstants.ENTITY)
  private User user;

  @Persist(JpaPersistenceConstants.ENTITY)
  private Account account;