Quoting Mohan Radhakrishnan <[EMAIL PROTECTED]>:
> Hi
> I read the following spec. This means that in a clustered environment the
> application scope
> is useless.
Not true at all.
. I can't really believe this. Why do we have this scope then ?
>
A primary purpose for appication scope variables is to store an in-memory cache
of read-only data that is repeatedly used, but is shared across all users (for
example, an array of LabelValueBeans containing U.S. state appreviations and
their corresponding names). Typically, the data for such a cache is loaded
(from a database, or from properties files, or whatever) either at application
startup, or lazily loaded the first time it's requested.
This approach works fine in either a single-server or multi-server environment,
and will improve the response time of your application (by avoiding repeated
database loads of the same data) in either scenario. The fact that the same
physical instance of the in-memory objects is not shared doesn't matter -- an
appication receives the right data value no matter which server instance it is
running inside, because all the copies are duplicates.
For non-read-only-shared-data scenarios, you need to heed Section SRV.3.4.1:
When information needs to be shared between
servlets running in a distributed environment,
the information should be placed into a session
(see Chapter SRV.7, "Sessions"), stored in a
database, or set in an Enterprise JavaBeans component.
For other issues related to running applications in a distributed environment,
see SRV.2.2 and SRV.7.7.2. One of the most important features of session
management is that the container is *required* to serve multiple simultaneous
requests for the same session from the same server instance -- if the server
supports session migration, that can only occur "in between" requests. Thus,
your application can be assured that the same session will not be accessed from
two server instances at the same time, which makes sessions a good place to put
mutable data that needs to be available no matter where the session is moved.
Of course, such session attributes also have to be Serializable, but that is
generally pretty easy.
> Mohan
>
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
