Can it be important to call remove() on an EJB 3 stateless session bean? Perhaps on weblogic?

1
votes

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.

2
jakarta-eeglassfishejb-3.0weblogicejb
Any update? In EJB3, I see the client having to call the method annotated with @Remove. Also are you suggesting that stateless EJBs have no state? They do. They are stateless because they don't maintain conversational state between 2 method invocations (they do during a method invocation). – dalvarezmartinez1
@MichaelBorgwardt et al., As EJB 3 does not implement EJBObject, does the container return a direct reference of a local bean to a local client? If so, there are dangers like the client can assign a null value to same and pool instances will disappear from SLSB pools. If client calls are routed through a proxy as in EJB 2.1, what is such a proxy type? – lupchiazoem
@mnmopazem: it's now been too long a time since I worked with EJBs for me to remember specifics, but I would definitely assume that EJB3 local beans are given to clients as direct references - and if you think that assigning null to a reference could make instances disappear from a pool, you have some misconceptions of how references work. – Michael Borgwardt
@MichaelBorgwardt Its interesting to know about references. Could you elaborate on same. IOW, if a client holds a direct reference to a bean, why assigning null would'nt disappear it from pool. By, 'disappear' I mean it would be ready for GC as per runtime. I had posted a question @ stackoverflow.com/questions/51657404/…. I request you to share your know inputs there. – lupchiazoem
@mnmopazem: only if there are no other references to the object. But if you have an object that is assigned from a pool, the pool would also hold a reference to the object. Otherwise it would be eligible for GC after the client is done with it, setting the reference to null makes no difference at all to that. – Michael Borgwardt

2 Answers

1
votes

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.

0
votes

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