I have a Cocoon 2.2 webapp that uses xindice which I deployed
using a war file on a remote server running tomcat. It works fine.
When I use the Tomcat manager to stop and then start or
when I use the Reload button, the webapp appers to start,
but it will not work properly because a database lock file
has been left in place. The only way to restart the webapp
is to restart Tomcat on the server, which will stop everyone
else's applications as well. This seems like a Bad Thing.
Here's the message reported in the browser when the webapp
home page is reloaded:
**************************
Problem in creating the Request
Message: Unable to open lock file C:\Program Files\Tomcat 6.0\db\db.lock.
Make sure database is not open by another process. Exception:
java.io.IOException: Could not delete lock file.
**************************
Since the xindice database is part of my webapp and not part
of Tomcat, I would think this db.lock file should be removed
automatically when the webapp stops. Failing that, perhaps
xindice should notice out-of-date lock files when it starts?
And how would this work if other users deployed xmldb webapps?
They would all create the same lock file and jam up the database
for other users.
Any insights are appreciated.
-Hugh Sparks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
