The remove() method on a session bean signals to the container that you have
no further use for the calling instance. In the case of a stateless bean
this method is not that useful, however in the case of a stateful bean it
allows the container to release resources earlier than it otherwise would.
Stateful beans that do not have remove() called on them will be freed on
session timeout, avoiding the resource leak you allude to.

Feel free to take this discussion up with me off list; I'm not sure that
this is pattern-based any longer.

JT

-----Original Message-----
From: Arzamasov Alexey [mailto:AArzamasov@(protected)]
Sent: Thursday, 26 February 2004 14:22
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: Removing EJB Business Delegate


On Thursday 26 February 2004 09:41, Sean Brydon wrote:

> The EJB container maintains controls the lifecycle of session beans, so
> you do not need to call remove. It will create them and destroy them as
> needed. This is a nice feature of EJB containers since you are free to
> focus on the application business logic and let the conainer manage the
> object lifecycle.
>
> On entity beans you would call remove if you want to remove some data
> from the database.

I guess that one should call remove() on statefull session bean to signal to
container that this bean can be removed and do not need to be passivated.
I guess that not calling remove() will cause container to hold my statefull
session bean forever.
Is it wrong?

====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)