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 <[EMAIL PROTECTED]> 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 > >
