Can it be important to call remove() on an EJB 3 stateless session bean? Perhaps on weblogic?
- by Michael Borgwardt
I'm in the process of migrating an EJB 2 application to EJB 3 (and what a satisfying task it is to delete all those deployment descriptors!). It used to run on Weblogic and now runs on Glassfish.
The task is going very smoothly, but one thing makes me wary: The current code takes great care to ensure that EJBObject.remove() is called on the bean when it's done its job, and other developers have (unfortunately very vague) memories of "bad things" happening when that was not done.
However, with EJB3, the implementation class does not implement EJBObject, so there is no remove() method to be called. And my understanding is that there isn't really any point at all in calling it on stateless session beans, since they are, well, stateless.
Could these "bad things" have been weblogic-specific? If not, what else? Should I avoid the full EJB3 lightweightness and keep a remote interface that extends EJBObject? Or just write it off as cargo-cult programming and delete all those try/finally clauses?
I'm leaning towards the latter, but now feeling very comfortable with it.
