All of William's point about my points are good ones.
The point about performance and per-session Connections is very
valid... I would advocate this mainly on intranets where the numbers
of users is not to great and very predictable.
It's a bit of a dirty trick really and for an application that may
have to scale very rapidly to many users I wouldn't recomend it.
As for pooling PreparedStatement - it really depends on the SQL
engine you're using. A lot of webapps are written with cheap SQL
engines and I've never been to sure about how reliably they deal with
parsing a SQL query.
JDBC also has to do query parsing (to provide the portability across
different SQL syntax environments) and using a PS does mean that the
parsing only needs to happen once.
If you had a very loaded app that could use pooled PS's it would be
worth experimenting to see if getting rid of the parsing overhead did
you any good.
As a final point I think the answer to many web/sql problems is the
idea of a Connection that can be re-authenticated (ie: when you log
out the TCP connection remains until you actively disconnect).
Add timeouts to the picture and you would have the best of both
worlds (of pooling Connections and having them per-user).
Unfortunately JDBC out of the box doesn't allow this - SQL engines
also rarely provide the opportunity to maintain persistent connections
across authenticated sessions.
If JDBC and SQL providers would make this happen it would greatly
benefit us all.
Nic
PS: I have actually been planning to do the persistent connection
thing (with PostGres) for absolutely ages but just haven't had the
time - ah well.
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
