ALRubinger wrote :
| ...if you set stuff in a ThreadLocal, ensure that its removed if the Thread
has been obtained from a Thread pool. Otherwise, nightmares.
|
Thanks ALR, I'll watch out for that
ALRubinger wrote :
| Or in your case...if you don't want to put any JPA stuff in your DAO
I'd be interested in hearing the JBoss take on this as well. For the small
discovery project I'm working on currently, I chose to pollute my BD and DAO
API's with entity manager parameters, while recognizing the design gap. I
can't however accept the same for the next and much larger project.
Done some more testing using the above ThreadLocal paradigm, because I was
worried about multiple serfver side threads and in particular if the JBoss
container ever uses 1 thread to service a session bean call.
But apparently it does not - I can happily kick off multiple (e.g. 100)
concurrent
Watch out for memory leaks in threads. I handled resources in a BEA deployed
app with thread locals. This the threads come from a cache, the thread local
will hang onto the reference, to whatever you put into it, even after the
session bean call is done.
View the original post :
A couple of years ago my company had an EJB training session w/ Bill. We had
expressed concern over our polluted method signatures and passing the same
variables all over the place.
He suggested the use of ThreadLocal, citing that it will have the same scope as
any one execution context (or
