I've had a very similar problem to your situation. I assume you want to have your session bean act like a class with static methods and static members. I solved this by having the session bean class itself access another helper class residing on the same VM. Tjhis helper class consists of static methods and members and thus does not need instantiation. Even though the stateless session bean is always "instantiated" on every creation request.. it still is able to access the "persistent" state of the helper class.
How did you get on with the static class -
I ask because I'm doing something similar.
I'm stashing all my home interfaces in static members as jndi lookups tend to be quite expensive - and while it works fine when I test it by myself, I cannot be sure how reliable this technique would be with multiple users in the real world.
Any insights would be much appreciated.
You can find a design pattern named service locator pattern at Sun Java Center J2EE Patterns site. There is a description of cashing performance at its consequences section. Generally speaking, however, I guess its technique may not work with clustering on client side.
This method will not work in a clustered environment. I had a similar problem and the solution that I came up with was to use rmi instead of a bean, or instead of a static class in your case. So, when the server starts up I start a rmi server on a specific port on a single server in the cluster and I bind an object. Then everywhere I need to access this object I do an rmi lookup since I know the server's IP and port. I set the server's IP in site wide settings used by my software. In theory you could detect if this call would be local and bypass the rmi lookup and stuff and thus speed up the process for most cases. Anyway, I have ranted enough...