Holding on to a Stateless Session Bean remote Interface

[nbirch]

Hi,

I have an app thats based on EJB1.1. It uses a separate process (with it's own main() ) that subscribes to a JMS bus topic, and sits there getting messages from that topic and then calling methods on the remote interface of a stateless session bean (as a Session Facade). The session bean then interacts with various Entity Beans.

So really, this separate process is behaving like a somewhat inefficient Message Driven Bean, i.e., it listens to a JMS topic and works with Entity Beans via a Stateless Session Bean. I'd like to get rid of this process and use a MDB, but I'd have to have the EJB1.1 and EJB2.0 co-existence.

My question is: Can this separate process keep the Session Bean remote interface object for ever, rather than keep the Session Bean's Home and then create a remote interface object every time it needs one????
When I first started working with this code it did create() on the home and a remove() on the session bean remote interface each time it processed a message from JMS. This added quite a lot of time to the message processing loop. So changed it to get the remote interface once and keep it for use within the message processing loop. The whole app is faster (obviously). The only complication is dealing with broken connections when the server dies/shuts-down. For that case I just catch a "java.rmi.NoSuchObjectException: no such object in table" exception. This gets thrown when I try to call a method on the session bean remote interface after the RMI connection is broken. Does this sound valid?

The reason I question keeping the session bean's remote interface object is that so much sample code I have seen will use the home to get the remote interface, do some work on the bean, and then call remove() on the remote interface. This is necessary for a transient 'user' such as a jsp, but if the 'user' is a process that stays up all the time, it seems valid to keep the remote interface.

Any thoughts would be welcome.

Thanks
Nbirch

[jonlee]

The home interface is the interface to the factory class for that EJB. The remote interface is the interface to a specific EJB instance.

Since SLSBs can get removed when the pool shrinks, the interface is invalidated. Depending on the shrinkage and load characteristics, you may have to deal with the exception catch and retrieve new interface scenario more often than you expect.

The greater problem is the pooling issue. The sensible EJB container would assume that without receiving the remove, the EJB must still be under use until a timeout occurs and the EJB is reaped and returned to the pool. Therefore, the next request for an instance will result in the creation of a new EJB. Since EJB creation is usually a complex and therefore lengthy process, if you have a lot of new sessions starting up, you can incur more resource usage as there is less sharing and perhaps greater average session times, due to creation, thrashing and so on.

So usually, it is a not good idea to hang on to an SLSB instance. YMMV but it is not good practice.

Hope that helps.

[nbirch]

Thanks for the reply. It is very helpfull.

Another data point on my process is that the message loop actually uses a HomeHandle to get the SLSB Home and then uses this Home to get the SLSB Remote for each message it gets from the JMS bus. Getting the Home from the Handle takes 10's of (and once 800) milliseconds. Getting the Remote from the Home takes 10's. So together its significant.

I'm guessing that removing the use of the HomeHandle to get the Home would be OK. Then its just normal home caching, and it would help my loop time. It still feels painful to have to create/remove the Remote each time.

You mentioned that "sensible" containers would not remove the EJB from the pool unless .remove() had been called or a non-use timeout occurred. Does JBoss do this?

What do you think about usng a MDB instead? Can it co-exist with all other EJB1.1 beans, or do I have to move everything to EJB2.0
An MDB would be better anyway since it would be in the same VM the SLSB, and so the optimized remote interface call would be used. Right now my standalone process is in its own VM and I suppose it is going over TCP to the SLSB?


Thanks,
NBirch

[jonlee]

Normally, you would look up the home reference once - i.e. do your JNDI lookup once. Just bear in mind that the home reference will probably change if you redeploy the bean because everything gets rebound. In a production instance, you would probably not see the bean get redeployed.

Since the home instance is the EJB factory, you just use the same home reference to create/retrieve the actual EJB instance from the pool.

The .remove() returns a used EJB to the pool so that another process may use it. Otherwise the EJB time-out will do the same. So JBoss will follow this action. The .remove() should also be enacted when the remote object is garbage collected but since the garbage collection is governed by collection cycles, you may not get immediate return of an EJB to the pool.

Operating with MDBs will not be affected by your other EJBs. In fact, JBoss 2.4.x implemented MDBs even though it had only EJB 1.1 support for the entity, stateful and stateless beans.

Yes. An in-VM invocation will be faster than an external invocation because it will not be conducted over the wire. If you need greater speed, go for a local interface as you do not need to perform the operations through an RMI object interface.