Re: Jetty, HSQLDB and automatic scanning
cool On Fri, May 28, 2010 at 11:49 AM, Jakub Skoczen wrote: > 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 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 > 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 > > >> 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 > >> 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: users-unsubscr...@wicket.apache.org > >> >> For additional commands, e-mail: users-h...@wicket.apache.org > >> >> > >> >> > >> > > >> > - > >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> > For additional commands, e-mail: users-h...@wicket.apache.org > >> > > >> > > >> > >> > >> > >> -- > >> > >> Cheers, > >> Jakub > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > > > -- > > Best regards, > > Paul Szulc > > > > http://paulszulc.wordpress.com > > > > > > -- > > Cheers, > Jakub > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Best regards, Paul Szulc http://paulszulc.wordpress.com
Re: Jetty, HSQLDB and automatic scanning
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 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 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 >> 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 >> 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: users-unsubscr...@wicket.apache.org >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> > >> > - >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> > For additional commands, e-mail: users-h...@wicket.apache.org >> > >> > >> >> >> >> -- >> >> Cheers, >> Jakub >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > -- > Best regards, > Paul Szulc > > http://paulszulc.wordpress.com > -- Cheers, Jakub - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Jetty, HSQLDB and automatic scanning
maybe you lack of shutdown=true ? shutdown=true shuts when connections are closed On Fri, May 28, 2010 at 10:53 AM, Jakub Skoczen 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 > 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 > 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: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > -- > > Cheers, > Jakub > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Best regards, Paul Szulc http://paulszulc.wordpress.com
Re: Jetty, HSQLDB and automatic scanning
Hmm wicket-cool generates project that uses embedded hsql as database and uses it for test in all modules (domain, service and webapplication) as well as for jetty:run deployment. I do not have problems you are speaking of so you might as well just try it. Here is what I did: jdbc.properties file looks like this: # connection driver=org.hsqldb.jdbcDriver changeLogFile=dbchangelogs/db.changelog.xml url=jdbc:hsqldb:file:hsqldbs/test.db;shutdown=true datasource.url=jdbc:hsqldb:file:../hsqldbs/test.db;shutdown=true username=sa password= # hibernate and jpa configuration hibernate.generate_statistics = true jpa.showSql = true jpa.database = HSQL and application context like this: On Fri, May 28, 2010 at 10:48 AM, Jakub Skoczen wrote: > Well, I'm using an embedded (in-process) HSQL, that's the very reason > I get this error. Is wicket-cool addressing this particular issue in > some way? > > On Fri, May 28, 2010 at 9:54 AM, Paul Szulc wrote: > > other solution would be to use embedded HSQL, if you want to know how > > checkout http://code.google.com/p/wicketcool/, generate project using > it, > > and check jdbc.properties in domain module. > > > > good luck > > > > On Thu, May 27, 2010 at 11:22 PM, Peter Ertl wrote: > > > >> maybe you should properly shutdown hsqldb in Application#onDestroy() ... > >> > >> Am 27.05.2010 um 19:00 schrieb Igor Vaynberg: > >> > >> > you can add a servlet context listener that looks for the lock file > >> > and nukes it. > >> > > >> > 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 > >> 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: users-unsubscr...@wicket.apache.org > >> >> For additional commands, e-mail: users-h...@wicket.apache.org > >> >> > >> >> > >> > > >> > - > >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> > For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > > > -- > > Best regards, > > Paul Szulc > > > > http://paulszulc.wordpress.com > > > > > > -- > > Cheers, > Jakub > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Best regards, Paul Szulc http://paulszulc.wordpress.com
Re: Jetty, HSQLDB and automatic scanning
(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 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 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: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Cheers, Jakub - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Jetty, HSQLDB and automatic scanning
Well, I'm using an embedded (in-process) HSQL, that's the very reason I get this error. Is wicket-cool addressing this particular issue in some way? On Fri, May 28, 2010 at 9:54 AM, Paul Szulc wrote: > other solution would be to use embedded HSQL, if you want to know how > checkout http://code.google.com/p/wicketcool/, generate project using it, > and check jdbc.properties in domain module. > > good luck > > On Thu, May 27, 2010 at 11:22 PM, Peter Ertl wrote: > >> maybe you should properly shutdown hsqldb in Application#onDestroy() ... >> >> Am 27.05.2010 um 19:00 schrieb Igor Vaynberg: >> >> > you can add a servlet context listener that looks for the lock file >> > and nukes it. >> > >> > 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 >> 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: users-unsubscr...@wicket.apache.org >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> > >> > - >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> > For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > -- > Best regards, > Paul Szulc > > http://paulszulc.wordpress.com > -- Cheers, Jakub - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Jetty, HSQLDB and automatic scanning
On Thu, May 27, 2010 at 7:00 PM, Igor Vaynberg 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 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: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Cheers, Jakub - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Jetty, HSQLDB and automatic scanning
other solution would be to use embedded HSQL, if you want to know how checkout http://code.google.com/p/wicketcool/, generate project using it, and check jdbc.properties in domain module. good luck On Thu, May 27, 2010 at 11:22 PM, Peter Ertl wrote: > maybe you should properly shutdown hsqldb in Application#onDestroy() ... > > Am 27.05.2010 um 19:00 schrieb Igor Vaynberg: > > > you can add a servlet context listener that looks for the lock file > > and nukes it. > > > > 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 > 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: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Best regards, Paul Szulc http://paulszulc.wordpress.com
Re: Jetty, HSQLDB and automatic scanning
maybe you should properly shutdown hsqldb in Application#onDestroy() ... Am 27.05.2010 um 19:00 schrieb Igor Vaynberg: > you can add a servlet context listener that looks for the lock file > and nukes it. > > 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 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: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Jetty, HSQLDB and automatic scanning
you can add a servlet context listener that looks for the lock file and nukes it. 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 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: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
