If you read the specifications, you will understand why session beans "stay
active" after an HttpSession expires. The basic premise is that expiring
HttpSessions do not imply anything about the lifetimes of SBs.
As for "trusting" the garbage collector to do proper cleanup, I think I've
already explained my views on why the clean up cannot be automatic for
non-trivial cases. It was the whole point of my previous email, and the
reason why I posted the original question.
Petr, try this little test: Create a session bean that allocates 1MB of
memory. Then have every new HttpSession instantiate this bean. Set the
HttpSession timeout to 1 minute. Create a bunch of new sessions and see
whether the SBs disappear after the HttpSession disappears. See whether the
garbage collector reclaims the memory allocated by those beans.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Petr Podsednik
Sent: Monday, March 26, 2001 12:00 AM
To: Orion-Interest
Subject: Re: Removing SBs when expiring HttpSessions ... the challenge
continues.
Gerald,
Thank you for your explanation.
But my question was a little bit different. I was wondering why to take care
of removing SBs when there is remote garbage collector which is responsible
for it. But maybe you want to make some special cleanning up or you are
facing another type of problems I am not aware of.
You wrote (snipped):
> ... to remove session beans that would
> > otherwise stay active and eventually consume all resources and cause the
> > server to crash.
>
My original question was: Why do you think that session beans would stay
active after expiring HttpSession? Don't you trust remote garbage collector
which I hope is responsible for cleanning invalid session beans instances?
Regards
Petr
----- Original Message -----
From: Gerald Gutierrez <[EMAIL PROTECTED]>
To: Orion-Interest <[EMAIL PROTECTED]>
Sent: Friday, March 23, 2001 8:07 PM
Subject: RE: Removing SBs when expiring HttpSessions ... the challenge
continues.
>
> As with anything, the devil is in the details.
>
> SBs expire in one of a number of ways. The two main ways are: you call
> remove() or they time out. This is well known. So if you have your SB
bound
> to an HttpSession, everything works and you get get your SB from the
session
> at any time.
>
> The REAL ISSUE is, however, the security issues with how you clean up that
> SB when the HttpSession expires. This is something it seems no one really
> understands, and it seems to me to be a fairly critical to the proper
> working of J2EE.
>
> The servlet spec does not say anything about WHO calls
> HttpSessionBindingListener.valueUnbound() when an HttpSession expires.
> Assume (arbitrarly) that it is an "unauthenticated user" (Orion calls this
a
> "guest"), then if you call ejb.remove() within valueUnbound(), the EJB
will
> be called with the guest user. Well, what if the remove() method is
> protected by security constraints and guest is not allowed? What if you
had
> to call other methods to clean up that session?
>
> Well, someone said "log in with a special user before calling remove()".
It
> doesn't work because one tries to JNDI-lookup a RoleManager to log in,
Orion
> throws an exception saying "javax.naming.NamingException: Not in an
> application scope". Okay, so just call remove() and do the login in there.
> That DID work, but WHY? I have my remove() method secured so only
> authenticated users can hit it. And what if you had to call OTHER methods
in
> addition to remove()?
>
>
> >From the responses, it seems either that no one has previously recognized
> this as a problem, or that they're ignoring it, or I'm just all wrong.
>
> So please, am I wrong, or is there an issue here?
>
>
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Petr Podsednik
> Sent: Friday, March 23, 2001 12:37 AM
> To: Orion-Interest
> Subject: Re: Removing SBs when expiring HttpSessions ... the challenge
> continues.
>
>
> Hi,
> If It is possible I have a question regarding this problem.
> Until now I was thinking there is no problem regarding HttpSession
expiring
> because of garbage collector which knows what remote references became
> invalid. Please tell me, if I am wrong and why. If it is must be handled
in
> code what about for example Swing clients machine's crashing?
> Regards
> Petr
>
> > When an HttpSession expires, it calls valueUnbound() on all
session-bound
> > variables that implement the HttpSessionBindingListener interface. So
this
> > provides a way for expiring HTTP sessions to remove session beans that
> would
> > otherwise stay active and eventually consume all resources and cause the
> > server to crash.
>
>
>
