Christopher Schultz wrote:
>Uh, oh. Are you doing something like this:
Possibly. I didn't write that code.
>If you're doing that, then you're probably making a big mistake. Are you
>storing connections in sessions or anything like that? Yuk.
For certain transactional operations, I think it is.
>>1. Thread 1 returns a connection with an uncommitted transaction to
the pool.
>Mistake: see above.
I know it's a mistake. I'm not sure that that is what is happening. It's
just a hypothesis.
>I'm still interested in what happens if you disable prepared statement
>pooling.
I finally figured out how to make the app use up the cursors consistently
so I tried disabling PreparedStatement pooling a few minutes ago. That
makes the problem go away. I can make cursors accumulate with it turned
on. I can't with it turned off.
That makes me think it's not the app after all.
However, it also makes me concerned about performance. Interactive
performance on my test machine is nice and fast. However, the performance
problems show up when the system is being pummeled by hundreds or
thousands of visitors to the site simultaneously (I have a script that can
simulate such pummeling against the server).
Would this then be considered a problem with DBCP's PreparedStatement
pooling?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
