On Jun 13, 2008, at 1:12 PM, Karsten Ohme 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?
Unfortunately, no. The session context is a read only object.
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?
A stateless bean is shared amongst multiple callers, but only one
caller will have access to the bean at a time. This means that a
stateless bean isn't well suited for storing state. The stateful
session bean was specifically designed to store state in it's fields.
The session bean can be notified of the transaction begin and
completion (commit or rollback), but rollback of the changes to
fields, it the responsibility of the listener code (which is a nice
way of saying you have to do it manually).
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.
Yes and no, the JNDI tree in general is global and shared. Each bean
type has it's own private java:comp/env, but it is shared with all
instances of the bean type and it is read-only.
Or is the only way to place a ThreadLocal variable in the java:comp/
env?
You can place the thread local anywhere. I'd personally use a static
field in a helper class.
If you code always starts a transaction, you can use the
javax.transaction.TransactionSynchronizationRegistry instance bound to
java:comp/TransactionSynchronizationRegistry. All JEE5 containers are
required to bind the registry at that location. The registry has nice
methods like getResource(Object key) and putResource(Object key,
Object value) that you can use to associate data with the current
transaction. The only drawback of this approach is you must have a
transaction otherwise you get an IllegalStateException
-dain
