EJB environment question (static helper classes)

Question

We're using JBoss as AS containing several stateless session beans.
Now, we have certain helper classes that are abstract and contain static methods. Is this a problem for the EJBs? All of them use these helper classes all over their methods. Are they sharing the static class and will slow down somehow? Or is each EJB using its version of the class and can run concurrently?
Should we rethink this and put an INSTANCE of each helper class in each ejb instead of using static methods in the helper class?
Now in EJB method:
Helper.calculateStuff();
Should it be?
Helper h = new Helper(); // defined when ejb is created
helper.calculateStuff();
Edited by: JAeon on Sep 8, 2008 12:21 AM
Edited by: JAeon on Sep 8, 2008 12:22 AM

Answer 1

>
The helper methods do database querries etc and return results that the EJB sends onwards to clients. If these methods
are NOT synchronized (and the ejbs share the static class) won't it cause concurrency errors? I think most of our methods are not
synchronized (and it doesn't seem to cause any concurrency errors so far... though the system have not beeen stressed test that much,
and concurrency bugs tends to pop up later and randomly :P).
>
No, if you dont have any static data variables in the Java classes, static method as such will not cause concurrency errors, and the methods should not be synchronized.
If you have any synchronized methods and they take a while to execute, that could become a bottleneck in itself, because different threads waiting for each other,
so make sure you dont have any synchronized methods where it is not explicitly needed.
Think of a static method (without static data in the class being manipulated) as a plain function in another programming-language.
>
We have some scaleability problems with the EJBs... It seems as if they do not run concurrently. If we do a stress test with several threads calling the EJBs their response time increases by a too large factor to feel comfortable...
>
Apparently, you do have a some scaling/concurrency problem, which could have many causes -- transaction locking and clashes in the database, poorly configured database, network congestion, problems in the EJB architecture, etc -- can be many reasons...
The general idea to debug, is first to find out exactly what calls in your code that take longest time to execute (profiling, logging, System.out.println's are useful) when you put parallel load on your system -- rather than just seeing "the whole application seems slow" -- from there you can move on, "divide&conquer" the problem, etc...