Sohan Fernando wrote:
> Hi,
> In the project I'm involved in, we are using Beans and JSPs. Some of these
> beans (*session* beans) have temporarily written information to a database.
> We want this change to become permanent *only* once the user has confirmed
> and has logged out properly.
>
> However, we need the following feature too:
> If a session times out (due to user inaction for too long), we wish to
> remove that temporary information from the database. So we need to to have
> a way to tell those Beans "hey, the session terminated, so please go and
> remove that information from the database".
>
> Our solution: what we are doing (and currently it seems to work) is:
> Let those beans implement HttpSessionBindingListener. Then, when the
> session ends for any reason, each bean gets unbound and hence receives a
> HttpSessionBindingEvent, and so each bean's valueUnbound() method gets
> called (and in here we put code to do whatever restoration of the database
> if neccessary).
>
> This does seem to work.
>
> However, we are somewhat anxious about the following possiblity:
> *Before* our valueUnbound methods finish executing, might not the servlet
> engine happen to do garbage collection, thus causing the bean to get
> destroyed?
>
> This seems a fair possiblity, because, the way I understand Java
> architecture, the instant the session ends, the beans that were bound to
> that session are now fair game for garbage collection;
That is not exactly (or necessarily) true. Let's look at what's going on for a
moment.
A Java object is subject to garbage collection when there are no "live" references
to that object from some other object. If there is at least one "live" reference,
the object cannot be collected.
Inside the servlet container, there is code that handles the invalidation of the
session. What that code typically does is walks through an enumeration of all the
session attributes, calling valueUnbound() on the ones that implement
HttpSessionBindingListener before removing them from the internal Hashtable or
whatever.
The point is, while that code is running, it has a live reference to the Hashtable
(or whatever) containing the session attributes. And that Hashtable has live
references to all the session attributes it has not yet deleted. So ... to make a
long story short ... the attributes are still alive (from a garbage collection
viewpoint) until *after* the valueUnbound() method returns.
> i.e., from this point
> of time onwards, we do not have any guarantee about the existence of these
> beans. So anytime the Java environment wants to, it has the right to kill
> any of these beans. Maybe 1 milisecond or 1 hour later, we don't know, but
> anytime it can be done...
>
> If that is correct, that means that sometimes the Listeners etc that we are
> using; well, sometimes the bean might get destroyed before it has time to
> finish restoring the database.
>
> Perhaps the official JSP or Servlet specification says something about this?
> However I have not found the information I need. Hope someone can help us!
>
There is lots to worry about when programming web applications using servlets and
JSP pages. Fortunately, this is an issue you don't need to be concerned about.
:-)
>
> Thanks in advance,
> Sohan Fernando
>
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
