The spec says that CDI container removes a SFSB when the scope's context is about to be destroyed. How does it exactly remove the EJB? It does not seem to be calling the method annotated with @Remove.
@Stateful
public class CustomerDAOImpl implements CustomerDAO {
@PreDestroy
public void onDestroy() {
//This is getting called as expected
}
@Remove
public void deleteMyBean() {
//This is not getting called!
}
}
So, CDI is technically doing what the spec says. The question is how is it managing to ask the EJB container to remove the instance? Thanks.
The Lifecycle of a Stateful Session Bean The client initiates the lifecycle by obtaining a reference to a stateful session bean. The container performs any dependency injection and then invokes the method annotated with @PostConstruct, if any. The bean is now ready to have its business methods invoked by the client.
The main difference between Stateless and Stateful Session Bean is that Stateless Session Bean is a business object without state (data) that describes the business logic while Stateful Session Bean is a business object with a state (data) that describes the business logic.
What is a Stateful Session Bean? A stateful session bean is a session bean that maintains conversational state. Stateful session beans are useful for conversational sessions, in which it is necessary to maintain state, such as instance variable values or transactional state, between method invocations.
An instance of a stateful session bean has a unique identity that is assigned by the container at create time. Stateless: A stateless session bean does not maintain conversational state. Instances of a stateless session bean have no conversational state.
I think the CDI container needs a hook into the EJB container to ask it to "do what you'd do if an @Remove method had just completed". Looking at EJB spec, EJB 2.1 had a mechanism for this in the interfaces you had to extend.
For obvious reasons, the container calling an arbitrary @Remove annotated method for the side effect is pretty ill advised.
As covener says this is done using an implementation specific EJB API, that isn't part of the EJB standard API.
As covener says, calling @Remove is NOT the right way to proceed. @Remove methods are called by users code, and tell the EJB container to remove the EJB. If you want a callback when the EJB is removed, use @PreDestroy.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With