Saleem Haseeb
2018-09-10 07:38:42 UTC
Hi,
I am trying to use sqlite in a web application on tomcat version 8.0.41
The driver that I use to connect to sqlite from within the web application is
<dependency>
<groupId>org.xerial</groupId>
<artifactId>sqlite-jdbc</artifactId>
<version>3.23.1</version>
</dependency>
I am using Linux to deploy the application and whenever there is a connection first made to the database I get the driver .so files created as below:
sqlite-3.23.1-71f96c59-5318-4b40-8505-8000876a12e7-libsqlitejdbc.so
sqlite-3.23.1-71f96c59-5318-4b40-8505-8000876a12e7-libsqlitejdbc.so.lck
in the contextDestroyed() hook I am trying to do something as following to deregister the driver on my classloader for the webapp like
private void deregisterDrivers() {
Enumeration<Driver> drivers = DriverManager.getDrivers();
ClassLoader cl = Thread.currentThread().getContextClassLoader();
while (drivers.hasMoreElements()) {
Driver driver = drivers.nextElement();
if (driver.getClass().getClassLoader() == cl) {
try {
logger.info("Deregistering jdbc driver: {}", driver);
DriverManager.deregisterDriver(driver);
} catch (SQLException e) {
logger.info("Error deregistering driver {} due to {}", driver, e);
}
}
}
}
the above as pointed out in some questions at stackoverflow says is implementation dependent, so I verified and found out that it does not delete those so and lck files.
As a workaround, I then tried in the same contextDestroyed method, to delete the .so and .so.lck files but then that creates files with the pattern .nfsyyyyyyy on my disk. These files seem like the driver files and for some reason, if I try to delete those as part of clean up, I get the message "Device is Busy" and the .nfs* files hang on the disk and also don't get removed by the OS.
I am struggling here to get rid of the drivers gracefully on application undeployment. Any help is appreciated!
Regards,
Haseeb
I am trying to use sqlite in a web application on tomcat version 8.0.41
The driver that I use to connect to sqlite from within the web application is
<dependency>
<groupId>org.xerial</groupId>
<artifactId>sqlite-jdbc</artifactId>
<version>3.23.1</version>
</dependency>
I am using Linux to deploy the application and whenever there is a connection first made to the database I get the driver .so files created as below:
sqlite-3.23.1-71f96c59-5318-4b40-8505-8000876a12e7-libsqlitejdbc.so
sqlite-3.23.1-71f96c59-5318-4b40-8505-8000876a12e7-libsqlitejdbc.so.lck
in the contextDestroyed() hook I am trying to do something as following to deregister the driver on my classloader for the webapp like
private void deregisterDrivers() {
Enumeration<Driver> drivers = DriverManager.getDrivers();
ClassLoader cl = Thread.currentThread().getContextClassLoader();
while (drivers.hasMoreElements()) {
Driver driver = drivers.nextElement();
if (driver.getClass().getClassLoader() == cl) {
try {
logger.info("Deregistering jdbc driver: {}", driver);
DriverManager.deregisterDriver(driver);
} catch (SQLException e) {
logger.info("Error deregistering driver {} due to {}", driver, e);
}
}
}
}
the above as pointed out in some questions at stackoverflow says is implementation dependent, so I verified and found out that it does not delete those so and lck files.
As a workaround, I then tried in the same contextDestroyed method, to delete the .so and .so.lck files but then that creates files with the pattern .nfsyyyyyyy on my disk. These files seem like the driver files and for some reason, if I try to delete those as part of clean up, I get the message "Device is Busy" and the .nfs* files hang on the disk and also don't get removed by the OS.
I am struggling here to get rid of the drivers gracefully on application undeployment. Any help is appreciated!
Regards,
Haseeb