Essentially this results in creation of a few HashMaps... Not very
expensive by itself. My note on performance was mostly related to the
fact that DataContext level caching will not have a chance to play
significant role in a short-lived context.
Andrus
On Mar 18, 2008, at 2:35 AM, Gary Jarrel wrote:
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
