We can basically group state into two general groups ? session and long-lived. State that must live longer than a single user session must be persisted to a data store. In most applications, this data is retrieved upon request so the application code can operate on the data and perhaps display it to the user. Session state is created for only a single user session and may or may not be persisted. This session state is used by the application for processing current user information that is irrelevant beyond the current use by the user.
The reason state becomes important is for performance issues. Many applications will perform poorly if all data is always retrieved from the database every time the user or application needs to access it. Retrieving the data once and caching it for further use can often increase performance. Developers must then decide where to cache the data.
For many applications the performance is best when the data is cached as closely to where it is used as possible. For data that is displayed this means caching it in the presentation tier. For data that is not displayed but is accessed by the business logic of the application this means caching the data in the business tier. In a SOA application, this data would be cached with the services.
The complexity of the application increases with the number of locations where the data resides. Whenever the data changes, developers must ensure that the data always stays in sync. Since the data in the database is typically considered the "real" data, anytime a cached data is modified it must be persisted and all cached versions refreshed.
This was first published in December 2002