Win a copy of Practical SVG this week in the HTML/CSS/JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Database "process" breaks between two Tomcat versions

Mike Fourier
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a production app that runs just fine under Tomcat 4.1.31. I'm making changes to it, and on my dev server, I am using Tomcat 5.0.28

Between TC 4.1 and TC 5.0.28, the commons-dbcp and commons-pool upgrades look like:

Why provide this info? Well, the code in question is a long-running report that uses temp tables in a Sybase database. That would be tables defined with a "#" as the first character of their name.

Now, *as far as I can tell*[1] the code in question obtains a single connection, and passes it back and forth and "up and down" method calls.

First, the method issues a statement such as:

"Drop table #groupingTempTable"

Which resulted in:
com.sybase.jdbc2.jdbc.SybSQLException: Cannot drop the table '#groupingTempTable', because it doesn't exist in the system catalogs.

So, I then commented out the part of the code that "cares" that this statement fails (don't cry to me that a temp table doesn't exist... just go ahead and create it in your next step).

So then, it presumably still failed, but was quiet about it, and then made this statement:

"Create table #groupingTempTable (grouping numeric(10))"

But then it said:

com.sybase.jdbc2.jdbc.SybSQLException: #groupingTempTable not found. Specify owner.objectname or use sp_help to check whether the object exists (sp_help may produce lots of output).

After looking at it sideways and tracing through method calls and trying to find where it's using two different connections (and failing to find that incorrect coding, but I'm still looking)... I came to the theory that something about the connection itself was somehow.... not stable. That somehow, my connection was 'loosing' track of its temp tables. That is: that somehow, I have a "pointer to a pool-managed connection object" that is very stable in the production version, but is unreliable in my dev version.

I then began to think about "what changed in DBCP?" and that's why I listed the versions above.

Except.. that seems like madness, and a sure recipe for calamitous bug reports against DBCP. How could using temp tables ever work, if the pool kept swapping connections on you?

Anyways... I thought I'd throw that out there, in case anyone else has experienced something similar, or has other theories.

[1] I've looked and looked, but maybe that just means I haven't looked long enough/hard enough yet. But... I'm reasonably certain the code does *not* use two connections. Otherwise, for the years this app has been in production, every single time the improperly coded method (the one that obtains a connection, creates a temp table, returns that connection, then gets a new connection, and expects the temp table to be there) is being used, wouldn't it need to be lucky every time, that on subsequent calls to "getConnection()" that the pool returned "the right" connection every time? The error I'm seeing *every* time in dev, would have to occur at least *some* of the time in production, wouldn't you think? So while possible, it's unlikely to be improper application coding (and plus, I still can't find the improper dual connections yet).

I've tried looking here:, but alas, they change report doesn't go back far enough.

I thought I'd ask here, because Tomcat users (in my experience) tend to encounter lots of DBCP issues, and so might be aware of DBCP changes.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!