Ok. Now that I've manually reduced my duplicate stack dumps so that they're readable, I see that I do indeed have four separate threads hitting the database at the same time, and three of them are using the same runtime. So apparently my app isn't as serialized as I had previously thought. I guess the real surprise is that it works as well as it does with only 3 database connections in the pool. I'll raise that up to 5-to-10 and probably be good for another decade :) Thanks for the hints, Andrus.
On Fri, Jun 12, 2015 at 11:21 AM, Mike Kienenberger <mkien...@gmail.com> wrote: > Hmm. I just remembered that I have a second infrequently-accessed > database which is also configured. > > So I'd really have 3 runtimes * 2 connection pools, so that explains 6 of the > 8. > > Not sure where the other two are from unless I have a 4th runtime that > I've overlooked. > > > On Cayenne 4, yes, that's one of my goals this summer -- upgrade to > Cayenne 4. Probably won't happen until July, though. > > > I'm going to add something that will dump all threads when this > exception is hit. > > On Fri, Jun 12, 2015 at 11:15 AM, Andrus Adamchik > <and...@objectstyle.org> wrote: >> >>> On Jun 12, 2015, at 6:09 PM, Mike Kienenberger <mkien...@gmail.com> wrote: >>> >>> And, interestingly enough, I only have 8 "PoolManagerCleanup" threads, >>> and not the 9 that I expected. Maybe they are create-on-demand and >>> one of my runtimes hasn't needed it yet? >> >> There should be 3 actually. One per PoolManager, not one per connection. So >> something may be going on there. >> >> FWIW 4.0.M3 (master branch) has a completely new non-blocking alternative to >> PoolManager. The cleanup process is also more sane there. >> >> Andrus >>