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.
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?
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.