I did some more thinking about this and I think that the CME is related
to the connection problem.
I think that a bean is failing to get a connection, so I tries to
destroy itself and release its connections. Then (because of the
initial connection problem) it hits an exception trying to release its
resources, which causes it to try to destroy itself and release its
resources...
So, the iterator is already created further down the stack and trying to
remove an element from it is not permitted - Causing the concurrent
modification exception.
If it were not for the exception being thrown, I think that it might
have actually ended up causing an infinite loop.
Could a flag be set in the context that indicates that the exit is in
progress? Then the exit routine could first check for the flag and only
be allowed to proceed if it is not already in progress somewhere else in
the program stack.
Or, if folk think this might be right (the recursive exiting), what
about just catching the CME and letting the routine fail gracefully?
Jay
Matt Hogstrom wrote:
On Apr 7, 2007, at 6:34 PM, Matt Hogstrom wrote:
I'll give it a spin tonight Jay...thanks
I did some work over the weekend with little success. I started using
Derby as the DB provider and ran into a set of issues around
connection management (no concurrent modification exceptions). In
JDBC mode things ran fine. In Session Direct Mode I experienced the
connection problem. Basically it was complaining about a queue being
full in the exception but I didn't get too involved in diagnosing that.
Chris, did you run this with Derby or another external DB? Curious
where the fault domain might be for this problem.
I'll continue to work on this, but I want to stay on top of 2.0 as
there are lots of things to chase down wrt to dependencies so I can't
commit a lot of time to diagnosing this problem. Chris, what's your
ability to work on this?
