HI Mark, I tried by creating a standalone application and to my surprise, there are no .so and .so.lck files generated. I used the same dependency and everything seems fine! I am wondering what should I try now. Is it tomcat that is messing stuff for me? Any help is appreciated in this direction
Regards Haseeb -----Original Message----- From: Mark Thomas [mailto:ma...@apache.org] Sent: den 10 september 2018 10:17 To: users@tomcat.apache.org Subject: Re: tomcat and sqlite On 10/09/18 09:12, Saleem Haseeb wrote: > HI Mark, > The jar file is in the application lib so yes, under WEB-INF/lib > directory :) Thanks. That de-registration code looks to be correct to me. I suspect that this might require a change in the Driver. Some things to test: - can you delete the files if you shut Tomcat down first? - how does the driver behave if you access it via a stand-along Java application I suggest you try and recreate this with a stand-alone Java app and if you still see the problem. If you do, I'd suggest opening an issue against the driver. Mark > > Regards, > Haseeb > > -----Original Message----- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: den 10 september 2018 10:08 > To: Tomcat Users List <users@tomcat.apache.org> > Subject: Re: tomcat and sqlite > > On 10/09/18 08:38, Saleem Haseeb wrote: >> 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.l >> c >> k >> >> 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! > > Where is the JDBC located? &CATALINA_BASE/lib, WEB-INF/lib, somewhere else? > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
