RE: Removal of SBs from expiring HTTP sessions ...
Can't you just make the SB a HttpSessionBindingListener and implement valueUnbound() ? -mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Gerald Gutierrez Sent: Friday, March 16, 2001 9:33 AM To: Orion-Interest Subject: Removal of SBs from expiring HTTP sessions ... I posted this msg this morning, but I haven't seen it appear on the list yet. I'm reposting in case it was lost ... Session beans (SBs) must have their remove() methods called in order to "clean up" and return to an app server's object pool. I believe one common use of SBs is to create them and then bind them to HTTP sessions so that they can be reused by clients on subsequent requests. There's no standard way to tell when an HTTP session expires. How, then, is it possible for the remove() method to be called to release a SB? Does this not cause "memory leaks" to occur in two ways: 1) resources created by the SB are not released, and 2) the SB itself is not recycled?
RE: Removal of SBs from expiring HTTP sessions ...
Does that actually work in the remote EJB model; I mean through the stubs? If not, the servlets using the sessions could just as easily listen and in turn inform the SB's. tim. Can't you just make the SB a HttpSessionBindingListener and implement valueUnbound() ? -mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Gerald Gutierrez Sent: Friday, March 16, 2001 9:33 AM To: Orion-Interest Subject: Removal of SBs from expiring HTTP sessions ... I posted this msg this morning, but I haven't seen it appear on the list yet. I'm reposting in case it was lost ... Session beans (SBs) must have their remove() methods called in order to "clean up" and return to an app server's object pool. I believe one common use of SBs is to create them and then bind them to HTTP sessions so that they can be reused by clients on subsequent requests. There's no standard way to tell when an HTTP session expires. How, then, is it possible for the remove() method to be called to release a SB? Does this not cause "memory leaks" to occur in two ways: 1) resources created by the SB are not released, and 2) the SB itself is not recycled?
RE: Removal of SBs from expiring HTTP sessions ...
I can't see why this wouldn't work in the EJB model. I have other EJBs which implement interfaces such as this. -mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Endres Sent: Friday, March 16, 2001 11:19 AM To: Orion-Interest Subject: RE: Removal of SBs from expiring HTTP sessions ... Does that actually work in the remote EJB model; I mean through the stubs? If not, the servlets using the sessions could just as easily listen and in turn inform the SB's. tim. Can't you just make the SB a HttpSessionBindingListener and implement valueUnbound() ? -mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Gerald Gutierrez Sent: Friday, March 16, 2001 9:33 AM To: Orion-Interest Subject: Removal of SBs from expiring HTTP sessions ... I posted this msg this morning, but I haven't seen it appear on the list yet. I'm reposting in case it was lost ... Session beans (SBs) must have their remove() methods called in order to "clean up" and return to an app server's object pool. I believe one common use of SBs is to create them and then bind them to HTTP sessions so that they can be reused by clients on subsequent requests. There's no standard way to tell when an HTTP session expires. How, then, is it possible for the remove() method to be called to release a SB? Does this not cause "memory leaks" to occur in two ways: 1) resources created by the SB are not released, and 2) the SB itself is not recycled?
Re: Removal of SBs from expiring HTTP sessions ...
Hello Gerald,
You can create an object that implements HttpSessionListener
interface and override the valueUnbound method to call the
remove method or whatever you need to to with the SB.
Put it in the session, and when the session expires the
valueUnbound method is invoked. Be sure to implement the
java.io.Serializable interfaz to allow session persistence across
server restarts.
We use this technique for our Shopping Cart, and it has worked
pretty well so far.
Here is the class we use:
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
import com.enkamino.cart.*;
/**
*
* @author Rafael Alvarez
* @version 1.1
*/
public class ControlSesion implements HttpSessionBindingListener,java.io.Serializable{
ShoppingCart cart; // This hold the reference to the SB, becuse
// you can't access to the session to retrieve
//it.
/** Creates new ControlSesion */
public ControlSesion(ShoppingCart cart) throws java.rmi.RemoteException{
this.cart = cart;
}
public void valueUnbound(final javax.servlet.http.HttpSessionBindingEvent be) {
try {
this.cart.clear();
} catch (Exception e) {
java.rmi.RemoteException re = new
java.rmi.RemoteException("Error clearing the Cart ",e);
re.printStackTrace();
}
}
public void valueBound(final javax.servlet.http.HttpSessionBindingEvent be) {
}
}
GG I posted this msg this morning, but I haven't seen it appear on the list
GG yet. I'm reposting in case it was lost ...
--
Best regards,
Rafaelmailto:[EMAIL PROTECTED]
