I found that (here: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1114) exactly ten minutes ago and was just about to post back here :) . What's important - it works, so my connection string looks like this:
jdbc:hsqldb:file:temp_db;shutdown=true Thanks for all the ideas! On Fri, May 28, 2010 at 11:07 AM, Paul Szulc <[email protected]> wrote: > maybe you lack of shutdown=true ? shutdown=true shuts when connections are > closed > > On Fri, May 28, 2010 at 10:53 AM, Jakub Skoczen <[email protected]> wrote: > >> (sorry if that gotten reposted, I mistakenly used a different email >> address that may have not been registered with the ML) >> >> On Thu, May 27, 2010 at 7:00 PM, Igor Vaynberg <[email protected]> >> wrote: >> > you can add a servlet context listener that looks for the lock file >> > and nukes it. >> >> I had a similar idea for a while but hoped for a cleaner approach. >> Anyways after reading through the docs it looks like HSQLDB is using >> the standard Java lock file that gets released when the JVM exits, >> hence the issue. Nevertheless, you can force it to remove the lock by >> issuing SQL "SHUTDOWN" command to the DB. Now I'm trying to introduce >> that in some unobtrusive way - I hit the DB via Hibernate - maybe >> subclassing the DataSource would work. I'll see what I can come up >> with and report back. >> >> > alternatively you can use the Start class that comes with wicket >> > quickstart archetype/project that does what mvn jetty:run but with the >> > added benefit of allowing hotswapping, and in that class you can add >> > the code to nuke the lock file. >> > >> > -igor >> > >> > On Thu, May 27, 2010 at 9:57 AM, Jakub Skoczen <[email protected]> >> wrote: >> >> Hi Everyone, >> >> >> >> First of all - this question is not directly concerned with Wicket, >> >> sorry for that. But, I did came across this problem when developing a >> >> small Wicket web app, so I thought someone else here may have had a >> >> similar issue. So here it is: I got tired with the slow >> >> write/compile/deploy process and I switched to using jetty:run (with >> >> scanning interval set to 10s) and incrementally compiling the classes. >> >> Unfortunately, right after jetty detects changes to the compiled class >> >> and tries to redeploy the app I get the following HSQLDB exception: >> >> >> >> java.sql.SQLException: The database is already in use by another >> >> process: org.hsqldb.persist.niolockf...@7c137657[...] is presumably >> >> locked by another process. >> >> >> >> HSQLDB is run using the in-process mode and the following exception is >> >> thrown both when using memory and file backend. It obviously looks >> >> like HSQLDB is not releasing the lock during the auto redeployment, >> >> maybe Jetty is locking up the thread somehow? Anyways, any ideas will >> >> be greatly appreciated. >> >> -- >> >> >> >> Cheers, >> >> Jakub >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> >> >> >> -- >> >> Cheers, >> Jakub >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Best regards, > Paul Szulc > > http://paulszulc.wordpress.com > -- Cheers, Jakub --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
