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 <[email protected]> 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 <[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]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>


-- 
Best regards,
Paul Szulc

http://paulszulc.wordpress.com

Reply via email to