Daniel John Debrunner wrote:
[EMAIL PROTECTED] wrote:
Note A: You may want to create and use more than one connection to
increase performance if you have many simultaneous requests.
I would not recommend a single connection for any simultaneous requests.
Note B: If you're running with autocommit OFF, you should definately not
use the same connection object in multiple simultaneous requests (either
use synchronization or create multiple connections).
This is true even with automcommit on. Multiple threads using the same
connection with ResultSets will mess with each other, as per the JDBC
sprc. An executeQuery by one thread will close any ResultSet any other
thread is processing.
If you are running Derby embedded then the cost of creating a connection
per request will be much lower than traditional client server databases,
and most likely will be a small fraction of the cost of the query or update.
That's true, as long as the database is not booted & shut down with each
request. That was the case in the "prototype integration" described in
the referred article.
As long as the database is booted & shut down only in the context
listener class, it should be fine to create new embedded connections
with each request.
--
Oyvind Bakksjo
Sun Microsystems, Database Technology Group
Trondheim, Norway
http://weblogs.java.net/blog/bakksjo/
