Hi,

Your assumption may not be right in any servers.

In the ejb 2.0　spec, section 7.6.3 says "The Bean Provider cannot assume that the Container will always invoke the ejbRemove() method on a session bean instance".

The spec also suggests "The application using the session bean should provide some clean up mechanism to periodically clean up the unreleased resources".

But I wonder you could call a "disconnect" method in your case.

Miki

Ignacio,

You mention that you have a reference to a local
interface of a session bean. Is this session bean
stateful or stateless?

If the session bean is stateless, then calling
remove on the local (proxy) interface only serves
to invalidate that one proxy. This does not call
the ejbRemove() on an actual bean instance since
that proxy is *not* associated with a specific bean
instance.

The bean container decides when to call ejbRemove()
when it determines it needs more resources or it
times out.

If the session bean is stateful, then calling remove
on the local (proxy) interface should cause the
ejbRemove() of the actual bean instance for which it
is associated to be called and thus destroyed.

If a user were to have a duplicate reference to the
stateful proxy, then it should get a RemoteException
when invoking a method on the now destroyed bean
instance.

Cheers,

Noel.