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