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?
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>
>
