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.
That's right. You don't implement EJBObject in EJB 3 that's why you cannot call the remove() method. What actually the EJB 3 has, is the dependency injection, which works with the EntityManager.
Nowadays, I am migrating the applications from EJB 2.1 to EJB 3 and I have recognized that I could solve this problem via EntityManager
@Resource private EntityManager em;
and in a remove method you can write em.remove(yourObject);
Hope this helps