tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: How to remove stateful sessions programmatically ?
Date Tue, 28 Oct 2008 21:00:43 GMT

On Oct 22, 2008, at 4:11 AM, Jean-Sébastien Scrève wrote:

>
> Ok thanks for the tip David.
>
> What I try to implement is "conversation" between Tapestry and  
> OpenEJB. This
> "conversation" concept is already implemented into Seam.

Very interesting.

> I store the stateful instance into a web session and I'd like to  
> remove the
> instance as soon as the session expires.
>
> That's why I thought that an API that would allow us to remove  
> stateful
> could be helpful.

Another trick is to have an interceptor associated with the stateful  
bean that throws a runtime exception when you want to remove the  
stateful bean.  Any unchecked exception not marked as an  
@ApplicationException will cause the stateful bean (and the  
interceptors instances associated with it) to be discarded.  Not quite  
the same as @Remove as the @PreDestroy method of the stateful bean  
won't be called.  But is something you could use as a last resort.

> I know it already exists in OpenEJB but a standard API to parse  
> deployment
> information outside sessions beans could also be a nice thing.
>
> What do you think ?

I've actually been wanting to implement something similar, basically  
Stateful Session beans where the instance itself is tracked within the  
scope of the http session under the covers.  A Stateful Bean whose  
state is tied to the HTTP Session.  A Stateful HTTP Session Bean.  A  
Servlet could have a reference to one injected, not have to store it  
in it's HttpSession, and when it uses the reference we would under the  
covers delegate the call to an instance stored in the http session or  
create one if one didn't exist.  It would also make it so that several  
references to the same stateful bean in a webapp would all point to  
the same instance, rather than each getting it's own individual  
instance as they do now.

-David


Mime
View raw message