The notion
of being stateless is pretty confusing, because every application must maintain
some kind of state (for example, for runtime variables). Generically speaking,
a stateless application will follow the rule of a state per request, which means
that a state's lifecycle is the same as the request-response lifecycle. This is
an important issue in web applications, where we need to use
session/application scope that,
obviously, breaks down the notion of stateless.
Even so, one
of the most popular features of JSF 2.2 consists of stateless views (and is
actually available starting with Version 2.1.19). The idea behind this concept assumes
that JSF will not save/restore the view state between requests and will prefer
to recreate the view state from the XHTML tags on every request. The goal is to
seriously increase performances: the gain time used for the save/restore view
state, more efficient usage of server memory, more support for clustered environments,
and the prevention of ViewExpiredExceptions. So, JSF developers have certain
requirements of the stateless feature. Nevertheless, it seems that the
stateless feature doesn't affect too much of the time used for saving/restoring
the view state (this is not expensive, especially when the state is saved on a
server session and is not going to be serialized) and memory performances. On
the other hand, when an application is deployed on several computers (in
clustered environments), the stateless feature can be a real help because we
don't need session replication (refers to replicating the data stored in a
session across different instances) and/or sticky sessions (refers to the mechanism
used by the load balancer to improve efficiency of persistent sessions in a
clustered configuration) anymore. For stateless applications, the nodes do not
need to share states, and client postback requests can be resolved by different
nodes. This is a big achievement, because in order to resolve many requests, we
can add new nodes without worrying about sharing the state. In addition,
preventing ViewExpiredException
is also a big advantage.
Note Stateless
views can be used to postpone session creation or dealing with big (complex)
component trees that implies an uncomfortable state.
Starting
with JSF 2.2, the developers can choose between saving the view state and creating
stateless views in the same application, which means that the application can
use dynamic forms in some views (stateful) and create/recreate them for every request
in other views (stateless). For a stateless view, the component tree cannot be dynamically
generated/changed (for example, JSTL and bindings are not available in the
stateless mode) and resubmitting forms will probably not work as expected. Moreover,
some of the JSF components are stateful, which will lead to serious issues in a
stateless view. But, it is not so easy to nominate those components and the issues,
since their behavior is dependent on the environment (context). Some specific tests
may be helpful.
In order to
write a JSF stateless application, you have to design everything to work only
with the request scoped bean. In some cases, we can use different tricks to accomplish
this task, like using hidden fields and special request parameters for emulating
a session. While session and application beans will break down the idea of
stateless (even if it is possible to use), the view bean will act as request
beans.
Programmatically
speaking, defining a view as stateless is a piece of cake: just add the
attribute named, transient to the <f:view> tag and set its value to true.
Note that in order to have a stateless view, the presence of <f:view>
tag is mandatory, even if it doesn't have any other use. Each stateless view of
an application needs this setting because there isn't a global setting for
indicating that the stateless effect
should be
applied at the application level.
<f:view
transient="true">
...
</f:view>
When a view
is stateless, the javax.faces.ViewState value will be stateless, as shown
in the following screenshot:
You also may
be interested in:
Niciun comentariu :
Trimiteți un comentariu