Edoardo wrote
I have
resultset.close();
statement.close();
connection.close();
in my code.
and
connection = dataSource.getConnection();
seems very close to my
ambiente = (Context) new InitialContext().lookup("java:comp/env");
pool = (DataSource) ambiente.lookup("jdbc/myApp);
Connection conn = pool.getConnection();
there are a lot of debug information in my code and seems that nothing
is going wrong (no exceptions).
but... if you post that it means that I am doing something wrong.
Edoardo
I don't think so. Let me recap your problem:
When you undeploy an application from tomcat (using the DBCP pooling
mechanism) you can't make STRUCTURAL changes to the database because it
complains that connections are still in use.
This is exactly what one would expect. I've encountered the same
problem. When an application finishes with a database connection it is
returned to the pool. That's exactly what a connection pool is for!
As far as I can see by looking at the tomcat source code the connection
pool is created at startup and remains active until TC shutdown. Once a
connection has been obtained from the pool it may stay 'active' for the
entire duration of the TC session (that is, from TC start to TC stop)
Obviously, depending upon your usage, it is possible for more than one
application in the same container to be reusing the same connection
pool. Your original post indicates that only one app. is using the database.
It seems to me that:
1. you could just shutdown tomcat! If this is a production site the best
plan would be to write a script which renames the database and does
whatever else you need, test it on a development machine and just find a
'quiet' time to shutdown the site, update the db and restart.
2. Move the connection pool into your application. Thus shutting down
the application would shutdown the pool.
3. As I assume you are using DBCP in Tomcat, carefully read the DBCP
docs, configure your system so that you can directly access the POOLED
connections, keep a list of ALL the connections you use and then shut
them down at the end. This is fraught with difficulty.
Regards
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
