[ http://issues.apache.org/jira/browse/JCR-233?page=comments#action_12331133 ]
Tobias Strasser commented on JCR-233: ------------------------------------- i also opt for an exclusive file lock mechanism. i already have a patched version running...i will provide the patch shortly btw: you can use process explorer (http://www.sysinternals.com/Utilities/ProcessExplorer.html) to search the process that has locked the file and terminate it (like fuser on unix). sometimes it was even explorer.exe that had the lock. > repository lock file not removed without a clean shutdown > --------------------------------------------------------- > > Key: JCR-233 > URL: http://issues.apache.org/jira/browse/JCR-233 > Project: Jackrabbit > Type: Bug > Components: core > Versions: 1.0 > Reporter: fabrizio giustina > > actually when a repository is loaded a ".lock" file is created. This file is > removed only after a clean shutdown but, if a jackrabbit instance has been > killed, you have to manually delete the file in order to load the repository > again, also if there was no live instance of jackrabbit that was using it. > The problem comes from the fact that the simple presence of the .lock file is > used to indicate a live instance. > I suggest replacing this behavior using this method (used for example by > eclipse when opening workspaces): > - when an instance is loaded create a ".lock" file and open it with exclusive > access > - when a new instance is started try to delete an eventual .lock file. Only > if the file can't be deleted because in use assume that another jackrabbit > instance is running. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
