Obtaining principal in EJB helper classes

Question

I have a pretty typical EJB setup where the actual EJBs delegate a lot of work
off to helper classes which are simple java classes. Some of these helpers need
access to the principal currently executing on this container thread. Currently,
I am passing the principal as a parameter in every method signature on the helpers
which need it. But as you can probably guess that approach is quickly becoming
unweildy.
Ideally, what I would like to do is to have access to the principal associated
with the currently executing thread. I can mimic this by setting thread-local
variables in the EJB prior to calling helpers. But I was wondering (ok, hoping)
that there was already a way to access this information (either through weblogic
classes or MBeans). At this point, I dont even care if it is not portable.
P.S., I use WL6.1
Thank you in advance,
Steve

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