Had a look through the code and it seems the design doesn't leave for
much of a choice other than the thread local. If you still have time
to tackle it, go for it. It'll definitely solve the issue.
Maybe down the line we can look at reworking this code to be a bit
less awkward and avoid the thread local.
-David
On Apr 12, 2009, at 4:12 PM, David Blevins wrote:
Taking a look at what we did in 3.0, which had simpler code for
handling some of this stuff. Intellij is not behaving though and
seems to refuse to generate a project that works for the 3.0.x branch.
Would be great to get by without a thread local and just a stronger
try catch block, but it might be a bigger change.
-David
On Apr 12, 2009, at 2:12 AM, Bharath Ganesh wrote:
something like - "boolean discardInstance". This boolean could be
set to
false when an exception occurs during the call flow.
Set to "true" :-)
On Sun, Apr 12, 2009 at 1:31 PM, Bharath Ganesh
<[email protected]> wrote:
Hello,
I was looking at Jira OpenEJB-976 [1], the bean pool leak issue
when a
RuntimeException is thrown during txPolicy.commit(). (See
*StatelessContainer
# invoke()* method)
Currently there are a lot of places where we do *discardInstance
*and *poolInstance.
*It will be a nice idea to refactor this a bit to make the post-
Invoke
pool management at a single place - The ideal place being the
*finally *block
in the container's *invoke() *method, just before
*ThreadContext.exit(oldCallContext).
*
For this to happen, we would have to add a state to callContext
(ThreadContext), something like - "boolean discardInstance". This
boolean
could be set to false whenever an exception occurs during the call
flow. At
the end of the call, depending on this boolen we take a decision
to add the
instance back to pool or to discard it. If people are okay, I am
ready to
submit a patch.
Thanks,
Bharath
[1] http://issues.apache.org/jira/browse/OPENEJB-976
