Use of Static methods by EJB's

[ahmad namini]

Hi all:
I am developing a session EJB which invokes a static method of a third-party library packaged as a jar file. I have access to the jar file source code. My app server is JBoss. The question is:
Do mutiple instances of my session bean treat the static method as a singleton for each session bean, or is the static method a singleton for all session beans?
Thanks.

[Chris Mathews]

The use of the word Singleton is inappropriate. A Singleton means there is only one instance of the object at any given time. When using static methods there is not even a single instance created so there is no instance to share or not share between your session beans.

[Simon Brown]

"KillerAppRanchHand",
Thanks for joining JavaRanch, but could you just take a quick look at the naming policy and edit your profile.
Also, only members with valid names will be eligible for the book giveaways.
Thanks
Simon
Bartender (moderator) of "J2EE and EJB" forum

[ahmad namini]

Sorry all about my name.
The word singleton was used inappropriately, but I still reiterate the intent of my question.
Since a static method resides in global dseg space, is the implication that only all EJB instances which invoke the static method are in face invoking only one method.
If so, is there a better way to insure better runtime performance.
Thanks.

[Dave Landers]

Static methods and fields are tied to a Class. The class is loaded by a ClassLoader.
The concept of "Singleton" is really questionable, especailly in an AppServer. Here I am refering not so much to Singleton as a design pattern, but to the traditional implementation of a Singleton that, in Java, eventually relies on a static "instance" field.
Also, by "questionable", I do not mean that Singletons (and/or static methods) are not applicable or useful. But I mean that the questionable part is "How Single is a Singleton".
The answer is "it depends". It depends on how the class is deployed (made available to ClassLoaders) and also depends on the ClassLoader archtiecture of your appserver.
I can not talk specifically about JBoss because I just don't know. But most AppServers use ClassLoaders to support isolation between EJBs and/or WebApps and/or EARs. ClassLoaders are also used to support dynamic reloading ("hot-deploy").
So it depends on how your code is deployed on the system.
If you put the jar in CLASSPATH before you started the server, then the Class will be loaded by the System ClassLoader, which is a parent to all other ClassLoaders your appserver might create. Thus every session bean, servlet, etc in that JVM will use the same Class object and run the same static method and share any static fields.
If the jar is referenced from the EJB's Manifest Class-Path (or the class is actually included in the ejb-jar), then it will be loaded by that EJB's ClassLoader. Here things start to becom appserver dependent because the Specs dont talk about this.
In WebLogic, for example, all EJBs in the same Enterprise App will share a ClassLoader, so that Class and its static methods would be shared by everything in the EAR (including ejbs and webapps). But other applications (or EJB jars deployed outside an application) would not use that Class instance - they would either have nothing or have their own copy.
Another questionable thing about Singletons in J2EE is when you start to deploy your applications to a cluster. Then, things get weirder, because even the same EJB is deployed in multiple JVMs and of course has multiple ClassLoader instances - so it can not possibly share the same static fields or methods.
So the things to consider are:
Make sure you understand the architecture of your AppServer
Know how you are deploying the code, and thus how it will loaded by the AppServer
Understand how the above will affect the "Scope" of your "Singletons"

[Eduard Manas]

Namini,
Although I don't understand very well your question (sorry!), I think I know where you are going.
You need to be careful when you want to use Singletons in J2EE. There are well-known patterns for this.
First of all, I don't think the EJB spec allows static methods in entity beans for the simple reason that clients would not be able to access that method through the remote interface.
Secondly, even though a static method is common for all objects of a class, this only applies for objects in the same JVM. The problem in J2EE is that you can deploy the same EJB in different containers, thus different JVMs. You can then imagine that EJBs in different containers will invoke different static method.
Hope this helps
Eduard

[Tim Holloway]

Not only does it make the Powers That Be happier when people use real names instead cutesy hacker handles or obvious pseudonyms, "Real People" usually get faster answers here.
What can I say? We like to delude ourselves that we're professionals, "Ranch" theme notwithstanding
you should NEVER assume that declaring a variable static makes it unique in a server environment. Both the presence of multiple virtual machines and of alternate classloader can cause multiple "static" realizations. If singularity is a must, your best bet in J2EE is usually to provide a system-wide unique access point such as a Stateful Session EJB and let it do the accessing. If you do that, you won't need to have to pull apart the 3d-party source code, and thus you'll have one less component that has become uniquely yours to break.
"Efficiency" is seriously overrated as a programming virtue. A good design is almost always an efficient one and it's reliable too. An "efficient" design that's not a good one is a nightmare.

[Kalpesh Soni]

http://edocs.bea.com/wls/docs70/programming/classloading.html