tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Store data in SessionContext
Date Mon, 16 Jun 2008 18:14:20 GMT
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

Mime
View raw message