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 not feeling very comfortable with it.
I’m not familiar with WebLogic’s implementation, but I can’t imagine that it’s important. I expect each method invocation on an SLSB wrapper to allocate a bean from the pool before the method invocation and free it after, so there is nothing for remove() to do.
I would write it off as cargo-cult programming. As a guess, someone once forgot to call remove for an SFSB and found that bad things happened, so the pattern was extended to all session beans.