title: Can it be important to call remove() on an EJB 3 stateless session bean? Perhaps on weblogic?
body: <p>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.</p>
  
  <p>The task is going very smoothly, but one thing makes me wary: The current code takes great care to ensure that <code>EJBObject.remove()</code> 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.</p>
  
  <p>However, with EJB3, the implementation class does not implement <code>EJBObject</code>, so there is no <code>remove()</code> 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.</p>
  
  <p>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 <code>EJBObject</code>? Or just write it off as cargo-cult programming and delete all those try/finally clauses?</p>
  
  <p>I'm leaning towards the latter, but not feeling very comfortable with it.</p>