Thank you for the quick reply.
I know I should probably do some of my own profiling, but is the process of
creating a new datacontext expensive computation wise?
Thank you!
Gary
On Tue, Mar 18, 2008 at 4:55 AM, Andrus Adamchik <andru..bjectstyle.org>
wrote:
> The simplest thing to do is to limit the scope of the thread
> DataContext to the 'onMessage' method. I.e. create a new context on
> entry, bind it to the current thread, and unbind it in the "finally"
> block... The performance impact is of course that you need to refetch
> everything related to your processing on every call, which may or may
> not be a problem.
>
> Andrus
>
>
> On Mar 17, 2008, at 4:18 PM, Gary Jarrel wrote:
>
> > Hi All!
> >
> > One of the requirements of the current project I'm working on is to
> > use a
> > j2ee environment and message driven beans in an application server
> > such as
> > glassfish.
> >
> > There is also a requirement to use a custom DAO library which relies
> > on a
> > thread bound data context.
> >
> > Basically the message bean receives a text message via JMS an prior to
> > processing it, it must be stored in the database, then, once
> > processed the
> > results are also stored in a database.
> >
> > I've always tried to avoid EJBs however, in this case, my question
> > is: has
> > anyone got any "best practice" advice on how a data context should be
> > created and bound to the thread in a message bean environment.
> >
> > The message beans are quite simple, in that they only receive the
> > messages,
> > an then call upon spring POJOs to do the processing of the messages.
> >
> > Thank you in advance.
> >
> > garyj
>
>
This archive was generated by hypermail 2.0.0 : Mon Mar 17 2008 - 20:36:33 EDT