tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ravindranath Akila <ravindranathak...@gmail.com>
Subject Re: Non-Application Exception in Session Bean Cascades Destruction of Other Session Beans?
Date Fri, 18 Jun 2010 06:17:03 GMT
Thank you very much. Now I have to see why actually further calls hang.
Afaik new lookups on this outer bean does not fetch a new instance OR leaves
the thread hanging due to some problem of my own app. I'll check and see.
Probably something I am overlooking. Thanks again.

On Fri, Jun 18, 2010 at 7:26 AM, David Blevins <david.blevins@visi.com>wrote:

>
> On Jun 17, 2010, at 1:33 PM, Ravindranath Akila wrote:
>
> > Hello,
> >  Below I have pasted a non-application exception. (This is an exception
> > which occured due to an error in persisting an entity).
> >
> >  The problem I am facing is that,
> >
> >  The container will as expected, destroy the session bean in which the
> > non-application exception occurred.
> >  This session bean however, is a class variable injected into ANOTHER
> > session bean.
> >  This means, its destruction will cause the wrapping(enclosing) session
> > bean to be unstable too.
> >  However, does the container destroy this enclosing session bean too? Is
> > this scenario handled?
> >
> >  What happens to me is that I think a new lookup just leaves the thread
> > hanging.
> >
> >  Am I doing something wrong here? What happens to the enclosing session
> > bean? Am I to expect "Reference is Invalid" message?
> >
> >  Thanks in advance.
> >
> >
> >  P.S.
> >
> >  From the spec ejb-3_1-fr section 14.2.2
> >
> >  "• Unless the bean is a Singleton bean, no other method will be invoked
> on
> > an instance that threw
> > a non-application exception.
> >
> > This means that unless the bean is a Singleton the Bean Provider does not
> > have to perform any cleanup
> > actions before throwing a non-application exception. It is the container
> > that is responsible for the
> > cleanup."
>
> It definitely would destroy the "enclosing" bean if that bean did not catch
> the exception.
>
>
> -David
>
> --
Cheers!
  Akila...

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message