At first glance, I wonder if you are throwing a custom exception. I
suggest that you design a custom exception, attach all data to a
custom exception, and throw it when an exception occurs. Then, catch
the exception and you get the data you need because it is attached to
the custom exception. These are the basic building blocks of a
thread-safe mechanism.
I agree with you. Attaching exception-specific data to a session
context, a thread, and JNDI context is not a good idea in general.
Thanks,
At 04:12 PM 6/13/2008, you wrote:
Hi,
Maybe a very simple question, but I haven't found a solution:
Is it possible to store any data in the SessionContext of a Session Bean?
I have a stateless bean which executes a method. In this method
exceptions can be thrown and some critical data is touched. This
data cannot be kept in the persistence layer and rolled back
automatically in the case of an exception (performance reasons and
parallel execution does not allow this). So I have to keep manually
track of this data and roll it back manually. This method is used in
a chain of other services and if any of these services fail, the
rollback must take place. This is the reason I cannot catch it in
the method itself. So there is an interceptor which is placed in the
upper facade implementation which starts the service chain. In this
interceptor I catch all exception, want to read the data, roll it
back and throw the exception. But how to get hold of the data here?
Apart form this, I have tried to place it in the java:comp/env, this
seemed to work, but these values are global, right? Each call has
its own critical data, so the must be the same for the bean and the
interceptor.
Or is the only way to place a ThreadLocal variable in the java:comp/env?
Regards,
Karsten
