Pinghua Young wrote:
> Craig, I think you probably misunderstood my question. Our application
> has a requirement to clear some data stored in a user's session when
> an external event occurs. Or more precisely, here's what happens:
>
> #1. An external event occurs (eg weather goes bad);
> #2. It notifies one servlet housed in our web servlet application,
> and sends along a userID;
> #3. This servlet of ours then has to find out if this user is login
> to our web server or not;
> #4. If yes, then clear the data from his session, so that new data
> can be retrieved from database;
>
> With the current servlet API, I just can't seem to be able to do
> what I want without some sort of problems.
>
There are several ways to approach a problem like this that don't require you to scan
through the list of
active sessions (and that's good, because the mechanism to do so got removed in 2.1).
Here's one way that is
consistent with the usual JavaBeans design patterns (see the JavaBeans specification
for more information):
* The servlet that receives notifications about weather
changes is, or is associated with, an object that allows
you to register interest in hearing about events. Using
the usual JavaBeans naming patterns, you might have
methods like addWeatherChangeListener and
removeWeatherChangeListener.
* When a user logs on, one of the things you do
is store a new instance of a particular bean
(let's call it LoginBean) in the user's session.
* This LoginBean implements HttpSessionBindingListener,
so it's valueBound() method gets called when this object
is added to a user session. One of the things that you get
in the event argument is a reference to the session you just
got added to -- save this in a local instance variable inside
the LoginBean.
* When the valueBound() method is called, this object should
also register itself as an event listener for WeatherChangeEvent
events. This is done by calling the addWeatherChangeListener
method of the registration object described earlier.
* Whenever your servlet receives a weather change notification,
it constructs a WeatherChangeEvent and sends it along to
all the interested listeners (i.e. the LoginBean instances that
have registered themselves). Each receiver of the event can
look at the other properties of the event (such as the username)
to decide whether or not it is interested. Note that each receiver
can apply their own rules to decide what events are relevant --
you no longer have to centralize this decision as you would in a
model where the event sender was iterating through the user
sessions.
* If the receiving LoginBean is interested, it can access the session
that it's bound to (because we saved a reference to it in the
valueBound method), and it can therefore modify the user objects
stored in that session (or even invalidate it, if the event was
"Floyd is coming -- log off quick and get under cover!" :-).
* The valueUnbound() method of the LoginBean will be called when
the user logs off, or when the session is invalidated (such as on a
timeout). At that time, it should deregister itself as a listener for
the weather change events, because it no longer cares.
You will see this approach a lot in Model-View-Controller (MVC) based design patterns
and architectures. It is
particularly evident in GUI toolkits like AWT and Swing, but the event listener
concept is quite useful
generally in architectures where external stimuli causes things to happen
asynchronously. The design patterns
outlined in the JavaBeans Specification are very helpful in building classes that
implement this style.
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
