You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Karsten Ohme <wi...@t-online.de> on 2008/06/13 22:12:02 UTC
Store data in SessionContext
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
AW: AW: Store data in SessionContext
Posted by Ka...@t-systems.com.
Thanks, a lot.
WBR,
Karsten
> -----Ursprüngliche Nachricht-----
> Von: Dain Sundstrom [mailto:dain@iq80.com]
> Gesendet: Mittwoch, 18. Juni 2008 20:13
> An: users@openejb.apache.org
> Betreff: Re: AW: Store data in SessionContext
>
> On Jun 18, 2008, at 1:19 AM, <Ka...@t-systems.com>
> <Karsten.Ohme@t-systems.com > wrote:
>
> >>> Are static fields also allowed in interceptors like I
> want to do it?
> >>
> >> According to the spec they are not allowed, but it is an
> >> unenforceable and in my opinion a stupid restriction. To my
> >> knowledge no vendor actually stops you from using static
> fields. If
> >> you really really want to be spec compliant, put the
> actual field in
> >> another class.
> >> This is legal since EJBs are allowed to use other Java classes.
> >
> > So it is always the case that during the execution of a bean chain
> > each bean stays on the same server instance? Or can it be imagined
> > that some mechanism distributes beans to other VMs where the static
> > information is missing?
>
> In the early days, of EJB there were lots of ideas about how
> one could build an EJB server, which led to the restrictions
> section in the EJB spec. One or the more unique designs came
> from Enhydra, which envisioned a single EJB server running
> over a set of vms. The idea was this would make your
> applications scale effortlessly. I don't believe they ever
> finished building the system, and if they ever did, I doubt
> it would be very efficient given the cost of an rpc vs a
> local call. In the end the industry settled down to a single
> vm design and scaleability is achieved horizontally with
> homogeneous servers. I wish the spec committee would simply
> drop all of the restrictions and adopt the restrictions of Servlets.
>
> Anyway, I am not aware of any EJB implementations that
> automatically start distributing beans. A call to bean in a
> remote vm has such different behavior compared to local bean,
> that EJB server can't automatically start distributing beans
> remote VMs. When you have a truly remote call in an
> application, you typically need to design the application
> with this in mind, since remote calls can fail for random
> reasons, and local calls really only fail for a small set of
> known problems. As a programmer you are normally aware which
> beans are truely Remote because they have special
> configurations to tell the server where the bean is located,
> security requirements, and other rpc protocol information.
>
> -dain
>
Re: AW: Store data in SessionContext
Posted by Dain Sundstrom <da...@iq80.com>.
Karsten,
Gilbert makes a good point here, but I don't agree with all of it....
When using a static field in a enterprise application (e.g., EJB,
servlets, web-services, enterprise spring), you should be aware that
the static field will be private to each running instance of the
application. So if you have 100 VMs running your application, each vm
will see a different copy of the static variable. In the case you
laid out below, this is acceptable.
As for the rest... I disagree. This is a complex subject so please
bear with me. In JEE a application is not really a divisible unit.
This is really due to the introduction of local interfaces in EJB
2.0. In EJB 1.x you only had remote interfaces, so a server could
theoretically deploy an application with thee EJBs to three VMs with
one EJB on each VM. In EJB 2.x, a servlet or EJB can obtain a direct
local interface to a bean and pass non-serialzable data to the bean.
Whit the introduction of JPA in EJB 3.x the application has become
even more coupled. This means that unlike EJB 1.x an application
server can not blindly distribute the EJBs in an application across
multiple VMs. To automatically distribute the EJBs in an application,
the server would have to perform some very complex static analysis to
determine which components are making direct calls to other
components. I'm not sure this is even possible, and even if it were,
I don't think you would want to do it. A distributed call is very
very slow, fault prone, and involve distributed transactions. The
last point is particularly nasty as many databases don't properly
support distributed transactions and when there are machine failures,
part of you database can be locked until the transaction log on the
failed machines are recovered. Of course, you can always manually
divide up your application into a group of applications that work
together, and in that case you will be aware of the application
boundaries and the costs of crossing them. Also, never count out IBM,
expecially when running on their most expensive hardware... they can
do magic you've never even dreamed of. Unfortunately, if you want to
run on other (less expensive) systems, you can't expect magic.
Assuming that you agree that a JEE application can not be
automatically divided up by the server, how do you achieve scaling?
Well you can divide you application by hand and/or you can use
horizontal scaling. In a horizontal scaling, you run several VMs and
each VM has the same application code running. When a client request
comes in, a request router chooses a VM and forward the request to the
VM. Since each VM is running the exact same code the router could
theoretically pick a random node but since most applications use
either client-session data or have data caches (like JPA or
Hibernate), the router typically uses a sticky load balancing rule
that forwards all requests from a single client to the same machine.
Why sticky? Well, when you have client-session data, it is becomes
very expensive to transfer the client-session state state for each
call. Even more critical to performance, a client typically accesses
the same or closely related data over their session, so if you send
them to the same machine, there will be less cache faults (this is
super critical to DB applications).
For the request router, you can use something as simple as a web load
balancer assuming the clients always use HTTP to communicate with the
server (this is my recommendation). Alternatively, there are products
like WebSphere XD Dynamic Router that can perform routing for many
different kinds of protocols (like CORBA).
Hope that helps, and wasn't too confusing
-dain
On Jun 19, 2008, at 8:19 AM, Gilbert Carl Herschberger II wrote:
> Does any implementation of EJB container automatically distribute
> beans? Yes, IBM WebSphere.
>
> IBM WebSphere comes bundled with IBM i Series and z Series. For
> example, it provides support for distributing EJBs across a farm of
> containers, with a load-balancing and fail-over monitor. With an EJB
> container farm, an incoming request is dispatched to any container.
> A transaction is distributed, too.
>
> An EJB container farm is for enterprise-level runtime performance.
> Load-balancing enables the dispatcher to forward an incoming
> request to an "idle" EJB container. Fail-over enables the dispatcher
> to detect when an EJB container is no longer responding.
>
> As we know, a static field is unique within a classloader and does
> not participate in the serialization mechanism. Therefore, a static
> field does not work across passivate/activate. Any resource that
> must be "static" cannot be distributed. You can, and should, design
> with these limitations in mind.
>
> Static fields in an EJB are not "allowed" according to the
> specification. This rule is not enforced with an error message.
> Rather, it is a serious warning that static fields do not work as
> some might expect in an EJB container farm.
>
> Thanks,
>
> At 02:12 PM 6/18/2008, you wrote:
>> On Jun 18, 2008, at 1:19 AM, <Ka...@t-systems.com> <Karsten.Ohme@t-systems.com
>> > wrote:
>>
>>>>> Are static fields also allowed in interceptors like I want to do
>>>>> it?
>>>>
>>>> According to the spec they are not allowed, but it is an
>>>> unenforceable and in my opinion a stupid restriction. To my
>>>> knowledge no vendor actually stops you from using static
>>>> fields. If you really really
>>>> want to be spec compliant, put the actual field in another class.
>>>> This is legal since EJBs are allowed to use other Java classes.
>>>
>>> So it is always the case that during the execution of a bean chain
>>> each bean stays on the same server instance? Or can it be imagined
>>> that some mechanism distributes beans to other VMs where the static
>>> information is missing?
>>
>> In the early days, of EJB there were lots of ideas about how one
>> could
>> build an EJB server, which led to the restrictions section in the EJB
>> spec. One or the more unique designs came from Enhydra, which
>> envisioned a single EJB server running over a set of vms. The idea
>> was this would make your applications scale effortlessly. I don't
>> believe they ever finished building the system, and if they ever did,
>> I doubt it would be very efficient given the cost of an rpc vs a
>> local
>> call. In the end the industry settled down to a single vm design and
>> scaleability is achieved horizontally with homogeneous servers. I
>> wish the spec committee would simply drop all of the restrictions and
>> adopt the restrictions of Servlets.
>>
>> Anyway, I am not aware of any EJB implementations that automatically
>> start distributing beans. A call to bean in a remote vm has such
>> different behavior compared to local bean, that EJB server can't
>> automatically start distributing beans remote VMs. When you have a
>> truly remote call in an application, you typically need to design the
>> application with this in mind, since remote calls can fail for random
>> reasons, and local calls really only fail for a small set of known
>> problems. As a programmer you are normally aware which beans are
>> truely Remote because they have special configurations to tell the
>> server where the bean is located, security requirements, and other
>> rpc
>> protocol information.
>>
>> -dain
>
Re: AW: Store data in SessionContext
Posted by Gilbert Carl Herschberger II <gc...@mindspring.com>.
Does any implementation of EJB container automatically distribute
beans? Yes, IBM WebSphere.
IBM WebSphere comes bundled with IBM i Series and z Series. For
example, it provides support for distributing EJBs across a farm of
containers, with a load-balancing and fail-over monitor. With an EJB
container farm, an incoming request is dispatched to any container. A
transaction is distributed, too.
An EJB container farm is for enterprise-level runtime performance.
Load-balancing enables the dispatcher to forward an incoming request
to an "idle" EJB container. Fail-over enables the dispatcher to
detect when an EJB container is no longer responding.
As we know, a static field is unique within a classloader and does
not participate in the serialization mechanism. Therefore, a static
field does not work across passivate/activate. Any resource that must
be "static" cannot be distributed. You can, and should, design with
these limitations in mind.
Static fields in an EJB are not "allowed" according to the
specification. This rule is not enforced with an error message.
Rather, it is a serious warning that static fields do not work as
some might expect in an EJB container farm.
Thanks,
At 02:12 PM 6/18/2008, you wrote:
>On Jun 18, 2008, at 1:19 AM, <Ka...@t-systems.com>
><Karsten.Ohme@t-systems.com > wrote:
>
>>>>Are static fields also allowed in interceptors like I want to do it?
>>>
>>>According to the spec they are not allowed, but it is an
>>>unenforceable and in my opinion a stupid restriction. To my
>>>knowledge no vendor actually stops you from using static
>>>fields. If you really really
>>>want to be spec compliant, put the actual field in another class.
>>>This is legal since EJBs are allowed to use other Java classes.
>>
>>So it is always the case that during the execution of a bean chain
>>each bean stays on the same server instance? Or can it be imagined
>>that some mechanism distributes beans to other VMs where the static
>>information is missing?
>
>In the early days, of EJB there were lots of ideas about how one could
>build an EJB server, which led to the restrictions section in the EJB
>spec. One or the more unique designs came from Enhydra, which
>envisioned a single EJB server running over a set of vms. The idea
>was this would make your applications scale effortlessly. I don't
>believe they ever finished building the system, and if they ever did,
>I doubt it would be very efficient given the cost of an rpc vs a local
>call. In the end the industry settled down to a single vm design and
>scaleability is achieved horizontally with homogeneous servers. I
>wish the spec committee would simply drop all of the restrictions and
>adopt the restrictions of Servlets.
>
>Anyway, I am not aware of any EJB implementations that automatically
>start distributing beans. A call to bean in a remote vm has such
>different behavior compared to local bean, that EJB server can't
>automatically start distributing beans remote VMs. When you have a
>truly remote call in an application, you typically need to design the
>application with this in mind, since remote calls can fail for random
>reasons, and local calls really only fail for a small set of known
>problems. As a programmer you are normally aware which beans are
>truely Remote because they have special configurations to tell the
>server where the bean is located, security requirements, and other rpc
>protocol information.
>
>-dain
Re: AW: Store data in SessionContext
Posted by Dain Sundstrom <da...@iq80.com>.
On Jun 18, 2008, at 1:19 AM, <Ka...@t-systems.com> <Karsten.Ohme@t-systems.com
> wrote:
>>> Are static fields also allowed in interceptors like I want to do it?
>>
>> According to the spec they are not allowed, but it is an
>> unenforceable and in my opinion a stupid restriction. To my
>> knowledge no vendor actually stops you from using static
>> fields. If you really really
>> want to be spec compliant, put the actual field in another class.
>> This is legal since EJBs are allowed to use other Java classes.
>
> So it is always the case that during the execution of a bean chain
> each bean stays on the same server instance? Or can it be imagined
> that some mechanism distributes beans to other VMs where the static
> information is missing?
In the early days, of EJB there were lots of ideas about how one could
build an EJB server, which led to the restrictions section in the EJB
spec. One or the more unique designs came from Enhydra, which
envisioned a single EJB server running over a set of vms. The idea
was this would make your applications scale effortlessly. I don't
believe they ever finished building the system, and if they ever did,
I doubt it would be very efficient given the cost of an rpc vs a local
call. In the end the industry settled down to a single vm design and
scaleability is achieved horizontally with homogeneous servers. I
wish the spec committee would simply drop all of the restrictions and
adopt the restrictions of Servlets.
Anyway, I am not aware of any EJB implementations that automatically
start distributing beans. A call to bean in a remote vm has such
different behavior compared to local bean, that EJB server can't
automatically start distributing beans remote VMs. When you have a
truly remote call in an application, you typically need to design the
application with this in mind, since remote calls can fail for random
reasons, and local calls really only fail for a small set of known
problems. As a programmer you are normally aware which beans are
truely Remote because they have special configurations to tell the
server where the bean is located, security requirements, and other rpc
protocol information.
-dain
Re: AW: Store data in SessionContext
Posted by Ka...@t-systems.com.
> -----Ursprüngliche Nachricht-----
> Von: Dain Sundstrom [mailto:dain@iq80.com]
> Gesendet: Dienstag, 17. Juni 2008 20:39
> An: users@openejb.apache.org
> Betreff: Re: AW: Store data in SessionContext
>
> On Jun 17, 2008, at 6:15 AM, <Ka...@t-systems.com>
> <Karsten.Ohme@t-systems.com > wrote:
>
> > Hi David, hi Dain,
> >
> > I have tried to use the
> > javax.interceptor.InvocationContext.getContextData() approach.
> > Unfortunately it did not works, because The
> InvocationContext differs
> > for me. I have two Interceptor, one is picking up the
> necessary return
> > value for me the other should rollback it. The rollback interceptor
> > intercepts different methods, so the invocation context is
> different
> > and the contained map also.
> >
> > Now my choosen approach is to use a static ThreadLocal in one
> > interceptor.
> >
> > Question regarding this:
> >
> > Why are static fields allowed in stateless beans? In my EJB
> 3.0 spec
> > it is not allowed.
> >
> > Are static fields also allowed in interceptors like I want to do it?
>
> According to the spec they are not allowed, but it is an
> unenforceable and in my opinion a stupid restriction. To my
> knowledge no vendor actually stops you from using static
> fields. If you really really
> want to be spec compliant, put the actual field in another class.
> This is legal since EJBs are allowed to use other Java classes.
So it is always the case that during the execution of a bean chain each bean stays on the same server instance? Or can it be imagined that some mechanism distributes beans to other VMs where the static information is missing?
Regards,
Karsten
>
> -dain
>
Re: AW: Store data in SessionContext
Posted by Dain Sundstrom <da...@iq80.com>.
On Jun 17, 2008, at 6:15 AM, <Ka...@t-systems.com> <Karsten.Ohme@t-systems.com
> wrote:
> Hi David, hi Dain,
>
> I have tried to use the
> javax.interceptor.InvocationContext.getContextData() approach.
> Unfortunately it did not works, because The InvocationContext
> differs for me. I have two Interceptor, one is picking up the
> necessary return value for me the other should rollback it. The
> rollback interceptor intercepts different methods, so the invocation
> context is different and the contained map also.
>
> Now my choosen approach is to use a static ThreadLocal in one
> interceptor.
>
> Question regarding this:
>
> Why are static fields allowed in stateless beans? In my EJB 3.0 spec
> it is not allowed.
>
> Are static fields also allowed in interceptors like I want to do it?
According to the spec they are not allowed, but it is an unenforceable
and in my opinion a stupid restriction. To my knowledge no vendor
actually stops you from using static fields. If you really really
want to be spec compliant, put the actual field in another class.
This is legal since EJBs are allowed to use other Java classes.
-dain
AW: Store data in SessionContext
Posted by Ka...@t-systems.com.
Hi David, hi Dain,
I have tried to use the javax.interceptor.InvocationContext.getContextData() approach. Unfortunately it did not works, because The InvocationContext differs for me. I have two Interceptor, one is picking up the necessary return value for me the other should rollback it. The rollback interceptor intercepts different methods, so the invocation context is different and the contained map also.
Now my choosen approach is to use a static ThreadLocal in one interceptor.
Question regarding this:
Why are static fields allowed in stateless beans? In my EJB 3.0 spec it is not allowed.
Are static fields also allowed in interceptors like I want to do it?
WBR,
Karsten
> -----Ursprüngliche Nachricht-----
> Von: David Blevins [mailto:david.blevins@visi.com]
> Gesendet: Montag, 16. Juni 2008 23:55
> An: users@openejb.apache.org
> Betreff: Re: Store data in SessionContext
>
>
> 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
>
>
>
>
Re: Store data in SessionContext
Posted by David Blevins <da...@visi.com>.
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
Re: Store data in SessionContext
Posted by Dain Sundstrom <da...@iq80.com>.
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
Re: Store data in SessionContext
Posted by Karsten Ohme <wi...@t-online.de>.
Gilbert Carl Herschberger II schrieb:
> 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.
This approach does not work in this case. The information is only known
in the method in service A. If service B in the chain throws an
exception, which should also lead to a rollback of these information, I
do not have this information and so cannot use the custom exception. The
data is lost.
Regards,
Karsten
>
> 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
>
>
>
Re: Store data in SessionContext
Posted by Gilbert Carl Herschberger II <gc...@mindspring.com>.
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