tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Store data in SessionContext
Date Mon, 16 Jun 2008 21:55:21 GMT

On Jun 16, 2008, at 11:14 AM, Dain Sundstrom wrote:

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

Note that stateless beans are fine places for thread locals and statics.

Another API that might be useful is the  
javax.interceptor.InvocationContext.getContextData() Map.  You're  
allowed to get/set anything you like in that map and it will live for  
the life of the invocation.  Interceptors can pass each other data  
this way.  As well via the InvocationContext.getTarget() method you  
can get the bean instance itself that will be invoked.  Any number of  
interceptors can call methods directly on the bean instance, so you  
can expose any number of bean class methods directly to the  
interceptor that you don't have to even add to your business  
interface.  It's possible to use interceptors to inject data into the  
bean instance before an invoke or pull data out of the bean after an  
invoke, or other similar things.

-David




Mime
View raw message