tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Tomcat/JDBC Thin Client and Oracle SQL Parsing
Date Wed, 27 Jan 2010 18:58:19 GMT
Hash: SHA1


On 1/26/2010 12:40 PM, Dan Denton wrote:
> While it's possible there's something we missed, I would like to know
> if anyone out there knows why a webapp restart would cause the
> database to reparse and choose a new execution plan.

If the JDBC connection was a new one (because the webapp was restarted),
then the server may have seen the query as a brand-new query and chose
to re-parse it rather than using some cached compiled statement on the

I'm' sure there are lots of reasons why Oracle would re-parse and
determine a new plan for a statement:

1. The statement was actually different
2. The statement in the cache timed-out
3. One or more tables was changed structurally so the cache was deemed
4. One or more tables had their indexes updated so the cache was deemed
5. Oracle was restarted
6. Oracle got bored with the old plan and wanted to investigate it's

> I know of no queries that are made to the
> database immediately upon startup, and it's certainly not this one
> since the query is page specific.


> Immediately after restart, Oracle was processing the query for a
> certain page using an improper index that caused the page/query to
> hang.

So, was this immediately after restart (i.e. before you hit any pages)
or during the evaluation of a page? Your two statements appear to conflict.

It is possible that Oracle was processing a query from before your
webapp restarted?

Does the query itself look good? If so, Oracle shouldn't have choked on
it, even if it decided to change the plan for that query for whatever

Maybe I'm completely missing the point, here.

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message