> I've been dying to have usable PreparedStatements in my web application,
> but AFAIK this is still not possible given your description below.
> Assuming I can't dedicate a connection to each user (connections are
> pooled), even Server Side PreparedStatements are useless (since they fall
> out of context when the statement is destroyed, and I can't hold it
> without holding a client side PreparedStatement), right?
>
> Imagine an online catalog with millions of records, and we want to support
> searching and browsing. Parsing the initial search query will be quite
> expensive if there are a great many columns on the table, but each
> subsequent NEXT_PAGE click really just needs to re run the same query with
> new params passed to the limit and offset clauses. Virtually any website
> with a database backend will have some variation on this scenario, and
> caching the execution plans for these common queries could significantly
> improve performance in all these cases.
>
> I agree that server side prepared statements are useful even when we don't
> need to bind variables, but unless we have single user systems, neither
> definition gets us very far. Maybe if we could cache prepared statements
> in application code and dynamically bind them back to connections on each
> request we could make use of this functionality, but I can't see how
> recreating the prepared statement will ever pay off with connection pools
> in place.
>
> Mike
>
>
> Dimtry,
>
> Server side prepare does not map to jdbc concept of
> PreparedStatement and it is important to understand how they are not the
> same.
>
> Server side prepare means that you can parse and plan the statement
> once and reexecute it multiple times so:
> select foo from bar;
> becomes
> prepare <name> as select foo from bar;
> execute <name>;
> deallocate <name>;
>
> This applies to all sql statements. So server side prepared
> statements can equally be used for regular JDBC Statement objects as well
> as JDBC PreparedStatements.
>
> JDBC PreparedStatements provide an interface to bind values into a
> sql statement.
>
> Server side prepare provides the ability to reduce the overhead of
> parse/plan across muliple executions of a sql statement that may or may
> not have bind values.
>
> They are different even though they both have the word 'prepare' in
> their names.
>
> thanks,
> --Barry
>
>