Clients use the create and remove methods on the home interface of a stateless session bean in the same way as on a stateful session bean. To the client, it appears as if the client controls the life cycle of the session object. However, the container handles the create and remove calls without necessarily creating and removing an EJB instance.
When does a stateless session bean client ever use "remove" on the home interface(of the stateless session bean)?What the point of doing that when control of creating and removing a stateless session bean is in the hand of the container?
Thanks Peer.I understand the create() stuff.I think you misunderstood my question. I basically wanted to know ,when a client would ever call remove on a stateless session bean (seeing that that's what the spec says in that quote)
I think what Peer wanted to say is the following: The client often does not know by calling the no-args-create() which kind of bean he uses: stateless or stateful. So a client should always call remove when he's done to tell the container: "Hey, I'm finished with that bean, you can nuke it!" Of course: When you code EJB and client you know what kind of SessionBean you're using. But more often this is not the case, especially in bigger projects with strictly divided roles.
The client can always call remove on the home interface remove(Handle h), by passing the Handle to the component interface (EJBObject). This is the same as calling remove() on the component interface (on the EJBObject). Both these calls would destroy the client's dedicated EJBObject, be it a stateless or stateful bean.If it is a stateful bean, the bean also gets removed. If it is statless, all beans are in the pool and bean removal is not tied to client remove call. But the remove call for a stateless session bean would still destroy the EJBObject and any method calls after remove would result in an exception as the stub's EJBObject is no more